I thought it might be useful to follow up this discussion by examining
what the EJB 2.0 specification has to say on the topic.
<begin-spec-quote>
10.5.10 Concurrent access from multiple transactions
When writing the entity bean business methods, the Bean Provider does not have to
worry about concurrent access from multiple transactions. The Bean Provider may
assume that the container will ensure appropriate synchronization for entity objects
that are accessed concurrently from multiple transactions.
The container typically uses one of the following implementation strategies to achieve
proper synchronization. (These strategies are illustrative, not prescriptive.)
� The container activates multiple instances of the entity bean, one for each
transaction
in which the entity object is being accessed. The transaction synchronization is
performed by the underlying database during the accessor method calls performed
by the business methods, and by the ejbLoad, ejbCreate<METHOD>, ejbStore,
and ejbRemove methods. The commit-time options B and C in Subsection 10.5.9
apply to this type of container.
With this strategy, the type of lock acquired by ejbLoad or get accessor method (if a
lazy loading cache management strategy is used) leads to a trade-off. If ejbLoad or
the accessor method acquires an exclusive lock on the instance's state in the database,
the throughput of read-only transactions could be impacted. If ejbLoad or the accessor
method acquires a shared lock and the instance is updated, then either ejbStore or a
set accessor method will need to promote the lock to an exclusive lock (which may
cause a deadlock if it happens concurrently under multiple transactions), or, if the
Container uses an optimistic cache concurrency control strategy, the Container will
need to validate the state of the cache against the database at transaction commit
(which
may result in a rollback of the transaction).
It is expected that Containers will provide deployment-time configuration options
that will allow control to be exercised over the logical transaction isolation levels
that
their caching strategies provide.
� The container acquires exclusive access to the entity object�s state in the database.
The container activates a single instance and serializes the access from multiple
transactions
to this instance. The commit-time option A in Subsection 10.5.9 applies to this type of
container.
</end-spec-quote>
This is pretty hard stuff, so let me try to explain.
We can quickly write off the second bullet as being unscalable, since a single
instance of a particular entity must be shared by all transactions. This is therefore
describing pessimistic locking in the container, which is unscalable.
Within the first bullet, we have the following choices:
a) "ejbLoad or the accessor method acquires an exclusive lock on the instance's
state in the database"
This is pessimistic locking in the database, or basically the "SELECT ... FOR
UPDATE" model in Oracle. As the spec says, "the throughput of read-only
transactions could be impacted." That is, it will be unscalable.
b) "If ejbLoad or the accessor method acquires a shared lock and the instance is
updated, then ... ejbStore or a set accessor method will need to promote the
lock to an exclusive lock (which may cause a deadlock if it happens concurrently
under multiple transactions)"
This is the model based on lock promotion. Unfortunately this lock promotion
model is not supported by Oracle.
c) "If ejbLoad or the accessor method acquires a shared lock and the instance is
updated, then ... if the Container uses an optimistic cache concurrency control
strategy, the Container will need to validate the state of the cache against the
database at transaction commit (which may result in a rollback of the transaction)."
This is the verified update model. Unfortunately, this model is not supported by
WebLogic.
So, there are four models, two based on pessimistic locking (either in the container,
or in the database) and two based on optimistic concurrency (one depending on
a particular database feature, and the other depending on a particular appserver
feature). Unfortunately, the particular database feature is not provided by Oracle,
and the particular appserver features is not provided by WebLogic.
So I believe the question is still open: how to run a scalable application correctly
on WebLogic and Oracle.
Actually, one reader got back to me and pointed to one possible answer: use a
different persistence manager. That is, use something like TOPLink or CocoBase
to control the database access. This will work, of course, since these products
are sophisticated enough to provide the requisite features.
But if you want to go with what's in the box, you may be out of luck.
-jkw
"Jonathan K. Weedon" wrote:
> 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".
