Re: How to update multiple rows atomically

From: Marshall <marshall.spight_at_gmail.com>
Date: 29 Jul 2006 16:31:53 -0700
Message-ID: <1154215913.017120.240060_at_m73g2000cwd.googlegroups.com>


paul c wrote:

>

> I'm not trying to rain on the SQL parade, nor the bigger parade that
> marches relentlessly towards greater and greater complexity, but in a
> way, I find it all unsatisfying.

Paul,

I'm also unsatisfied.

I have done a fair bit of concurrent programming. I've become reasonably facile with locks and so forth, and can write complex multithreaded Java programs without deadlock or race conditions. (Mostly.) But I'm not happy with it. Even if *I* can do it, it is often the case that other people on my team can't. I think even the built-in support for concurrency in Java is too low-level. As has been said before numerous times, shared state concurrency is the wrong default.

I want a better model.

And by better, it has to include not only better handling of issues such as deadlock. It also has to be *simpler.* The simpler it is, the more people it will be accessible to.

Now on occasion I get to discuss some of these issue with the Great Minds of the Java universe. While aware of the problem, I don't think they appreciate sufficiently the necessity of a radical solution. Their current thinking is in the direction of lock-free data structures. However these strike me as being still too low-level. I still have to design some application protocol to make appropriate use of these lock-free collections. It seems to me the problem necessitates being able to *read* shared state and modify shared state based on the read. Just being able to do a lock-free insert into a collection isn't going to get you that.

I have had in mind for a while now the idea of comparing and contrasting various approaches to the problem. I am thinking specifically of starting with Dining Philosophers; it is a well known problem that manages to have some meat to it while still being quite simple. My first thought was to compare a Java-native concurrent implementation of Dijkstra's algorithm with one using SQL via JDBC. I see now that I have to consider the locking properties of the dbms in question, sigh. And I suppose I should also try to use the lock-free data structures new to java.util.concurrent.

We don't talk much about concurrency in the RM. I guess it feels like an implementation issue, but maybe it isn't, at least if we want to think about concurrent programs. TTM is silent on the issues of concurrency. I note the existence of various process calculi, such as the pi calculus and the flow calculus; somehow they are not appealing.

More discussion, please.

Marshall Received on Sun Jul 30 2006 - 01:31:53 CEST

Original text of this message