Re: Which transaction isolation level can prevent lost updates?

You can do it, but pessimistic locking opens a can of worms.

Oracle doesn't have a datatype or any other mechanism that ensures update collision detection. Using a timestamp from the application server doesn't work in a multi-processor or clustering implementation. because you can get duplicate timestamps. Also, PL/SQL run on the database server doesn't go through your app server. The only way to really detect update collisions is to compare the select/update values of every column in the WHERE, but when your table changes you have change your application.

And how are you going to resolve collisions when you do detect them? First come, first serve? Re-submit with confirmation? Are you going to do something different for online users versus background jobs?

"Arno Huetter" <huetter_at_grz.at> wrote in message news:a710c60d.0211262245.4c885a52_at_posting.google.com...
> "Brian E Dick" <bdick_at_cox.net> wrote in message
news:<yfJE9.29020$wc2.1290111_at_news2.east.cox.net>...
> > And your container doesn't give you hooks to modify the SQL before
> > submission to the RDBMS? What vendor?
>
> Brian,
>
> you are right, I could use bean-managed persistence, hence write my
> own SQLs, but I was not planing to employ it (breaking the chosen
> container-managed persistence approach) unless absolutely necessary.
> Most vendors implement pessimistic-locking on applicatin level, so the
> developer should not really be concerned with these kind of issues.
>
> Kind regards,
> Arno Huetter
Received on Wed Nov 27 2002 - 10:41:15 CST