Cedric,
As you say, supporting optimistic concurrency via the database is
easy for an appserver to do.
However, as you also say, you need to do selective updates, to
ensure that you don't "overwrite data written externally since the
transaction was begun."
Is such a feature provided in WL6 using EJB 1.1? I did not
believe so.
In which case, in WL using EJB 1.1, WebLogic will corrupt the database,
if you use optimistic concurrency. (Note that OC cannot be avoided
when clustering.)
Is this a valid statement?
<vendor>
Selective updates are provided by Borland AppServer, thereby
preventing database corrupting when using OC. This feature is
provided for EJB 1.1 today, and will also exist in our EJB 2.0 /
J2EE 1.3 product, out when the specs are completed.
</vendor>
-jkw
Cedric Beust wrote:
> > From: A mailing list for Enterprise JavaBeans development
> > [mailto:[EMAIL PROTECTED]]On Behalf Of Peter Verkest
>
> > Optimistic locking at the container would be great indeed, but
> > how about optimistic locking at the DB level?
>
> Most of the databases already offer this (starting with Oracle). It's the
> easiest option for an EJB container provider, we have almost nothing to do
> :-)
>
> > If we are working in a cluster with n nodes, is there any need to
> > ejbLoad an entity more than once per transaction then?
>
> No, but in the case of optimistic concurrency at the container level, a
> check will be needed when the transaction commits to make sure the UPDATE
> won't overwrite data written externally since the transaction was begun.
>
> --
> Cedric
===========================================================================
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".
