Re: Theoretical Basis for SELECT FOR UPDATE

Roy Hann wrote:
> "vc" <boston103_at_hotmail.com> wrote in message
> news:1128453433.143208.246170_at_z14g2000cwz.googlegroups.com...
> > The transactions deadlock because there is a *bug*: the programmer
> > neglected to eliminate non-serializable transaction histories. Any
> > transaction history whose serializability graph has cycles will
> > deadlock.
>
> All very erudite no doubt, but you asserted that spaghetti code caused
> deadlocks, which is just wrong and I showed you it is wrong.

First, there is nothing "erudite" about it, it's really basic stuff. You've posted a piece of "crystal clear, linear code" which nevertheless was broken. I showed how to fix it. That's all.

>
> Question: how can I know the serializability graph for a transaction I can't
> even find?

I apologize for having had misunderstood your situation. I have not realized you are dealing with someone else's code which is no fun.

>
> > The way to avoid the deadlock is naturally to eliminate
> > non-serializable histories. In SQL Server, one would use the UPDLOCK
> > hint:
>
> [snip]
>
> > In Oracle, SELECT FOR UPDATE is your friend.
>
> And in other products there are other equivalent hacks.

What exactly is your point regarding 'other equivalent hacks' that help to avoid deadlocks ? There is no single concurrency control mechanism mandated by some standard. One has to learn whatever tools the database one works with has to offer.

>
> Are you telling me that a sufficient knowledge of proprietary hacks makes it
> unnecessary to know where transactions start and what is included in them?

That's a very odd conclusion indeed to draw from my words. All I tried to show that the piece of code you've provided was broken and that it's relatively easy to fix it if one has basic understanding of what a database transaction is *and* what concurrency control a specific database uses. Is it too much to expect from a database programmer ?

>
> Roy
Received on Wed Oct 05 2005 - 02:18:25 CEST