Re: How to update multiple rows atomically

From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Sun, 30 Jul 2006 00:47:30 GMT
Message-ID: <CkTyg.28792$pu3.398058_at_ursa-nb00s0.nbnet.nb.ca>


Marshall wrote:

> 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.

The only really interesting thing I have read regarding concurrency and databases was in Dennis Shasha's performance tuning book. What was it again, though? One of these days I really do have to unpack. It's been a year and a day since the purchase of this house closed, and I still have not unpacked.

One of these days I have to get over this procrastination thing. Received on Sun Jul 30 2006 - 02:47:30 CEST

Original text of this message