Re: How to update multiple rows atomically
From: paul c <toledobythesea_at_oohay.ac>
Date: Sat, 29 Jul 2006 17:16:15 GMT
Message-ID: <zJMyg.268410$IK3.130124_at_pd7tw1no>
>> Marshall wrote:
>>
>>> What makes me think any of those things is my lack of a mental model
>>> of locking in DBMS products.
>>>
>>> So, *would* the above update, (or my earlier one) being made from
>>> a variety of processes, be subject to deadlock or starvation? It
>>> seems clear it would be immune to race conditions, but again
>>> I don't really have a sufficient mental model to say.
>>>
>>> Alternatively, the more important question is: what can I go read
>>> so as to be able to answer the above question myself?
>> Ah, now, there's the rub. Whether it might experience deadlock or
>> starvation or any other concurrency problem will depend on what
>> concurrency mechanisms the dbms implements, which concurrency options
>> the dba and various users choose, and how the dbms implements them. It
>> will also depend on the other concurrent queries.
>>
>> Most dbmses detect deadlock automatically and use timeout to deal with
>> starvation etc. They don't do much to prevent deadlock or starvation etc.
Date: Sat, 29 Jul 2006 17:16:15 GMT
Message-ID: <zJMyg.268410$IK3.130124_at_pd7tw1no>
Marshall wrote:
> Bob Badour wrote:
>> Marshall wrote:
>>
>>> What makes me think any of those things is my lack of a mental model
>>> of locking in DBMS products.
>>>
>>> So, *would* the above update, (or my earlier one) being made from
>>> a variety of processes, be subject to deadlock or starvation? It
>>> seems clear it would be immune to race conditions, but again
>>> I don't really have a sufficient mental model to say.
>>>
>>> Alternatively, the more important question is: what can I go read
>>> so as to be able to answer the above question myself?
>> Ah, now, there's the rub. Whether it might experience deadlock or
>> starvation or any other concurrency problem will depend on what
>> concurrency mechanisms the dbms implements, which concurrency options
>> the dba and various users choose, and how the dbms implements them. It
>> will also depend on the other concurrent queries.
>>
>> Most dbmses detect deadlock automatically and use timeout to deal with
>> starvation etc. They don't do much to prevent deadlock or starvation etc.
> > Well, crap. That's no fun. > > So, does this condition represent a theoretical limit, a lack of a > decent model, or just lousy implementations?
(An admittedly minor point - if I cared, I would bet that just as many do as don't. As you pointed out in another message, all a dbms has to do is always group physical updates in some canonical order to trump the four necessary conditions for deadlock. This is less scurrying around for the impl'n than detection. At one time, most mainframe programmers were quite aware of this and ensured it themselves. It seems some people disparage this as too optimistic and others as too pessimistic!)
p Received on Sat Jul 29 2006 - 19:16:15 CEST