To expand on Evan's answer:
WebSphere Application Server 4.0 (WAS 4.0), for example, allows you to
specify which EJB 1.1 Commit Option should be applied to each entity bean
type: Commit Option A, Commit Option B, or Commit Option C
**Commit Option A**
This option requires that the container has exclusive access to the entity
data in the underlying database (i.e., no other applications are also
accessing updating this data). With this option, the app server caches the
data, since it can be sure that no other application is updating it. WAS 4.0
uses pessimistic locking for entity beans using this option, meaning that
transactions accessing a given entity (i.e., primary key) queue up waiting
for the instance. This option reduces ejbLoad() calls, but on the other hand
concurrency can suffer. There is (at most) one bean instance per primary
key.
**Commit Option B**
This option doesn't require that the container have exclusive access to the
entity data in the underlying database. With this option, the app server
will use a bean instance per transaction. So if you have 10 concurrent
transactions accessing entity Foo/primary key X, you will have 10 Foo
instances for primary key X in memory at once. After a transaction ends, the
data in an entity bean instance is considered to be stale, so ejbLoad() is
always invoked at the beginning of a transaction. With this option, unused
beans are in the ready state as opposed to the pooled state. WAS 4.0 uses
so-called optimistic locking (really no locking at all) for entity beans
using this option. This means that all locking is delegated to the
underlying DBMS and is controlled by the transaction isolation level (which
in WAS 4.0 you can specify on a method-by-method basis).
**Commit Option C**
This option doesn't require that the container have exclusive access to the
entity data in the underlying database. With this option, the app server
will use a bean instance per transaction. So if you have 10 concurrent
transactions accessing entity Foo/primary key X, you will have 10 Foo
instances for primary key X in memory at once. After a transaction ends, the
bean is passivated. With this option, beans not participating in
transactions are in the pooled state (and hence ejbActivate() and ejbLoad()
is called at the beginning of each transaction). Commit Option C can use
less memory than the other options. WAS 4.0 uses the same "optimistic
locking" here as with Commit Option B.
WebLogic Server 6.0 (WLS 6.0) also uses pessimistic locking with Commit
Option A, and optimistic locking with Commit Option B. (As far as I know,
WLS 6.0 doesn't allow you to specify Commit Option C.)
Although there does seem to be a pattern of Commit Option A ---->
pessimistic locking in server, and Commit Option B/C -----> optimistic
locking in the server, it seems that Commit Options and server-side locking
are orthogonal concepts -- i.e., a smart app server could theoretically
implement a smart optimistic locking strategy for Commit Option A.
Evan's answer could be interpreted as saying that the app server locking
strategies don't apply to BMP beans ... they do. The app server's locking
strategy has nothing to do with CMP versus BMP. I think the point of the
answer is that with BMP, you have more control through SQL statements than
just specifying the isolation level.
You can read about these commit options in section 9.1.10 of the EJB 1.1
spec (or 10.5.9 of EJB 2.0 spec).
Laurel
-----Original Message-----
From: Evan Ireland [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, July 24, 2001 4:32 PM
To: [EMAIL PROTECTED]
Subject: Re: locking Entity Beans
Catalfano Anthony wrote:
>
> Is there a recommended pattern for locking an entity bean?
The pattern for CMP is: "choose an EJB server that allows configuration of
locking strategies - pessimistic or optimistic - such that your requirements
can be met".
If you are using BMP, use "select ... holdlock ..." or "select ... for
update"
etc. depending on your database.
> A usage scenario might be something like the following: There is an
'Order'
> entity bean that has a collection of LineItems. There is a store that
> submits a monthly order to our site. The monthly order is updated by many
> different store personnel but we must ensure that only one user updates
the
> Order at a time. I believe that locking is not addressed by the 2.0 spec.
>
> Thanks
>
> Anthony Catalfano
> Information Technology Analyst
> Deere & Company
> 309-748-5201
>
>
===========================================================================
> 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".
--
____________________________________________________________________________
____
Evan Ireland Sybase EAServer Engineering
[EMAIL PROTECTED]
Wellington, New Zealand +64 4
934-5856
===========================================================================
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".
===========================================================================
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".
