Re: Theoretical Basis for SELECT FOR UPDATE

Roy Hann wrote:
[...]

> Even the most
> crystal clear, linear code can deadlock.

Please provide an example.

> Deadlocks can always occur and the
> application always needs to be ready to handle them.

No argument about that.

>
> > 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.

I find it hard to accept the argument that you, as the application author, have no clue where you transactions start and end, and what statements it consists of, that you do not know how to structure SQL statements into stored procedures or some Java classes representing individual transactions.

> 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.

See above. Received on Tue Oct 04 2005 - 16:54:24 CEST