Re: Concurrency in an RDB

"Roy Hann" <specially_at_processed.almost.meat> wrote in message news:2rWdnfYdR4n_tOTYRVnyvwA_at_pipex.net...
> "David" <davidbl_at_iinet.net.au> wrote in message
> news:1165564572.553799.62710_at_f1g2000cwa.googlegroups.com...
> > Bob Badour wrote:
> > I don't have the RDB experience to know how often and to what extent
> > dead-lock seriously degrades performance. However, I have heard of
> > real cases where repeated dead-lock kills performance.
>
> Since you claim not to be a DB programmer I want to make sure I share the
> understanding of the words you're using here--and there are loads of DB
> programmers who use the same words and get it wrong.
>
> When you say "deadlock" do you mean a deadly embrace, in which no
> transaction can terminate even in principle? Or do you mean a prolonged
> wait for a lock?
>
> In principle a deadlock needn't cause a performance problem. It can, in
> principle, be detected quickly and resolved quickly. On the other hand a
> prolonged wait for a lock is just that. (Though I've seen the ghastly
term
> "livelock" used to describe it!)
>

First off, I agree that the term "livelock" is ghastly. But I've heard it used to describe a rather different scenario. Here it is:

The application load on the DB is such that deadlocks are frequent, and not merely 2 way, but frequently n way deadlocks. This means that n-1 contenders have to back off and try again, while one gets through. If the mean time of arrival of contender n+1 is short enough, and if deadlock resolution time is long enough, what can happen is a series of rollbacks and rertries that actually take longer, in wall clock time, than eliminating concurrency altogeter, and making each transaction wait for its turn. This is both ghastly and dismal. Received on Sat Dec 09 2006 - 19:56:54 CET