Re: Theoretical Basis for SELECT FOR UPDATE

"vc" <boston103_at_hotmail.com> wrote in message news:1128433702.824559.118100_at_g44g2000cwa.googlegroups.com...
> If one deals with spaghetti code, then short of redesigning your
> application properly so that it avoided deadlocks, there is not much
> choice but to restart the failed transaction.

Deadlocks are not cause by spaghetti coding. They are caused by the order in which operations by two or more concurrent sessions occur. Even the most crystal clear, linear code can deadlock. Deadlocks can always occur and the application always needs to be ready to handle them.

> What's unreasonable
> about restarting a transaction that failed due to a deadlock ?

I'm not getting through at all here.

Please give me the benefit of the doubt and look closely at what I am asking. The problem is not that I don't understand what SQL wants me to do. The problem is that (in general) I just can't restart the transaction because (in general) I have no idea where it began and I have no idea what it includes. It began implicitly sometime in the past and it has done who knows what since then. I might hope I can guess when it (should have) started, but I can't *really* know, except in special cases, because that is how SQL is designed.

I am not interested in tools which--with a sufficient amount of care and understanding--can be made to work right when solving toy problems. I want tools that are hard to use wrong, on an industrial scale; tools that impose discipline on large teams working on systems that develop over decades. Complex atomic statements seem a very useful step in the right direction.

Roy Received on Tue Oct 04 2005 - 16:19:24 CEST