Re: Theoretical Basis for SELECT FOR UPDATE

Gene Wirchenko wrote:
> On 4 Oct 2005 07:54:24 -0700, "vc" <boston103_at_hotmail.com> wrote:
>
> >Roy Hann wrote:
>
> >>[vc:]
>
> >> > 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.
>
> Please read more carefully. He has repeatedly said that he is
> working on large apps that have had many programmers.

Ah, sorry I missed that. But you can hardly blame the tools for the programmers unwillingness to use them. By tools, I mean the very well known stuff like stored procedures, Java/C++/whatever classes that allow one to structure the code. It's extremely naive to think that the S1,S2,..,Sn notation will lead to better coding practices in comparison to the S1;S2;...;Sn;commit; one. I'd hope that the database programmer would use stored procedures, or some such, even with the modern notation.

>
> The problem with walking into such a situation is that anything
> could have happened.

One can always walk out, a matter of chpice, no ?

>If the language allows you to shoot yourself in
> the foot, you can not assume that a previous programmer has not shot
> himself in the foot. It is too easy for your change to break some
> wonky code. It is fine to say that the other code should not have
> been written that way, but if it was written that way, that is the
> reality that you have to deal with.
>
> >> 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.
>
> With SQL statements just about anywhere, how do you isolate
> exactly what that transaction is? Yes, there may be a way for you to
> do it with the way that you code, and if others coded as you do, there
> would be no problem. However, since others are not restricted to your
> way, they can do pretty much anything. That has to be untangled. Mr.
> Hann is saying that it can not be done very easily at all.
>

If what you ("you" is an impersonal pronoun here) are doing is reverse engineering the existing code without any documentation or even oral tradition, then yes it is tough.

> Sincerely,
>
> Gene Wirchenko
Received on Tue Oct 04 2005 - 21:37:15 CEST