Cedric Beust wrote:
> > From: A mailing list for Enterprise JavaBeans development
> > [mailto:[EMAIL PROTECTED]]On Behalf Of Jonathan K. Weedon
>
> > Database based optimistic concurrency
> >
> > This corrupts the database, if done without verified updates
>
> No.
>
> Or rather, if it corrupts the database, pick another database vendor.
>
> The database is in charge of making sure the update is valid. If it is not,
> it should be rolled back.
>
> > So, you have a choice between unscalable (pessimistic locking, either
> > in an unclustered container, or in the central database) or incorrect
> > (due to unverified updates).
>
> Come on, Jonathan...
Cedric,
Although I appreciate the camaraderie, you seem to be side stepping the
question. The question is how do you recommend to customers that they
deploy an EJB application on WebLogic, using Oracle, in such a manner
that it both scales and is correct. I don't believe that to be possible with
the products currently on the market.
The reason is that the database does not automatically promote the read
locks obtained at load time to write locks. This feature would be needed
if the database were to handle the optimistic concurrency correctly. On
the other hand, if the appserver is to handle the optimistic concurrency
correctly, it needs to verify the updates.
Since Oracle does not provide the locking model that makes optimistic
concurrency easy for the appserver, and since WebLogic does not provide
the verified update model that makes optimistic concurrency easy for
the database, I don't believe optimistic concurrency can be used with
Oracle and WebLogic, without sacrificing data correctness.
I'd be interested to hear a complete and correct counter argument.
-jkw
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
