Re: Theoretical Basis for SELECT FOR UPDATE

David Cressey wrote:
[...]
>
> Actually, I'm reading vc's position as follows: Sloppy, undisciplined
> coding can lead to deadlocks. Careful programming practice can avoid
> deadlocks. Spaghetti code is just one instance of sloppy, undisciplined
> coding.
>

Yes.

> In any event, I disagree with that position, and I think your example shows
> that even careful coding can yield deadlocks.

How can the example represent careful coding if it unknowingly allows deadlocks ?

> I don't regard "hints" to the DBMS as part of "careful programming". I
> regard it as "getting physical with the DBMS".

What if there is no other choice ? Would you also object to Oracle's SELECT FOR UPDATE on the grounds of getting too physical ? If so what is the alternative for getting repeatable reads for example ?

> When an applications programmer starts issuing "hints" to let the database
> engine know what's really going on, I think the logical/physical boundary
> has become hopelessly blurred.

So how do you suggest a database programmer should go about writing concurrent applications without knowing anything about the specific database pecularities and tools such database has to offer ? This part of the database is very far from being standardized yet.

> To me, the application programmer is a
> COBOL or Java programmer, that knows enough SQL to use it as a data
> sublanguage. That's it.

Then the hypothetical application programmer, without any knowledge of concurrency control, would produce the kind of code Roy is dealing with now. Received on Wed Oct 05 2005 - 16:06:25 CEST