Re: Concurrency in an RDB
Date: Fri, 15 Dec 2006 00:03:31 GMT
Message-ID: <nDlgh.33056$cz.493682_at_ursa-nb00s0.nbnet.nb.ca>
paul c wrote:
>> Christopher Browne wrote: >> >>> In an attempt to throw the authorities off his trail, Bob Badour >>> <bbadour_at_pei.sympatico.ca> transmitted: >>> >>>> Transactions may acquire and release many locks over the duration of >>>> the transaction which may be orders of magnitude longer than the >>>> duration of any lock. >>> >>> Are you sure they ought to release them? >>> >>> I seem to recall there being some anomalies where, if locks get >>> released, it gets easier for deadlocks to occur... >> >> Well, I suppose never releasing any locks might reduce deadlock, but I >> think it would greatly increase the starvation problem.
>
> The 2PL protocol basically states that no locks are acquired after any
> locks have been released (see Gray). This definition of transaction is
> a very strict and safe one, although people often complain that it
> reduces concurrency. Safe in the sense that if followed, it guarantees
> that no commit will fail.
That then gets to the issue of what locks are we talking about. It is not reasonable for a transaction to hold a mutex on an interprocess message queue for instance.
> When I have heard such complaints, the lack of thought given to the
> transaction design was blatant, not to mention the lack of attention
> paid to the real business requirements. Often the design was a cookbook
> one that somebody had found useful elsewhere. The starvation problems I
> used to see often coincided with EAV designs where a dbms was taking
> locks left right and centre an nobody had any idea exactly what rows and
> tables were being locked without resorting to ponderous traces.
>
> Note that 2PL refers to logical locks, for example predicate locks, not
> the physical locks which might be taken by an engine for internal
> reasonbs and which might be very short-lived, as small as 100
> microseconds or maybe even less.
Yeah, like those locks! Received on Fri Dec 15 2006 - 01:03:31 CET