Oops. The first line should have read "... but optimistic locking ...",
which puts my response out of context. I'm going back to sleep now.
"Brian E Dick" <bdick_at_cox.net> wrote in message
news:LA6F9.43302$wc2.1564889_at_news2.east.cox.net...
> 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 - 13:09:36 CST
