Laurel,
Thanks for the clarification. I tend to think of Commit Option A
as a bit of a joke. The assumptions for this option (i.e. no external
acces to the data, probably no cluster unless you have a distributed
lock manager) are so unworkable that anyone interested in scalability
would be well advised to avoid the option. Note that caching is still
possible with Commit Option B if you have a decent implementation.
Laurel Neustadter wrote:
>
> 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".
--
________________________________________________________________________________
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".
