Hi Richard,
The Weblogic 5.1 deployment XML file
has a section where the isolation levels can be stated. If the concurrency
issues are taken care at the database level why do we need these isolation
levels set for the container?
Thanks,
Ashutosh
----- Original Message -----
From: "Richard Monson-Haefel" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, September 06, 2001 7:47
AM
Subject: Re: Concurrency in Entity
beans
>
> > > When multiple callers use the same primary key to access a
> > > bean, which I think generally results in the same EJBObject being used by
> > all
> > > callers to get to one entity bean instance
> >
> > What does happen when multiple callers use the same primary key? Do they
> > each get a separate EJBObject (with each having the same primary key) or
> > do they point to the same EJBObject?
>
> That depends on how the EJB platform is architected. Some servers will utilize
> a different EJBObject for each client entity reference, while others will force
> clients to share the same EJBObject for the same entity identity.
>
> In the first case responsibility for concurrency is really the responsibility
> of the database, as each EJBObject accesses the same data, independent of the
> other EJBObjects. The database enforces concurrency through transactions and
> row/table level locking (isolation levels). This is, I believe, the strategy
> used in WebLogic and in a lot of clustering architectures used by EJB vendors.
>
> When a EJB container is architected so that multiple client accessing the same
> entity identity use the same EJBObject, concurrency is managed by the container
> explicitly. The later strategy tends to offer stricter isolation of data and
> better insurance against reentrant and concurrent access to entity identifies,
> but the first strategy (multiple EJBObjects for a single entity identity) tends
> to be more performant because the container is leveraging the data locking
> (isolation) capabilities of the underling database. See Section 9.1.10 Commit
> Options for more insights into these strategies.
>
> There is, actually, a third architecture used by OpenEJB. In OpenEJB, there is
> a single EJBObject which is multiplexed to service all clients for a particular
> type of enterprise bean. In this case the EJBObject is shared by all clients
> for a particular container and is not specific to a single entity identity. In
> this case, responsibility for concurrency is pushed down to the database just
> as it was in the first strategy outlined above.( Actually this is not
> completely accurate since OpenEJB uses Castor JDO for CMP 1.1 persistence, it's
> Castor that is responsible for concurrency. This strategy was originally
> developed by Rickard Oberg for JBoss (which at that time was ejBoss) and is
> based on concepts gleaned from the use of the JDK 1.3 proxy facilities, which
> were first used (ASFAIK) by Orion to create lightweight client stubs for
> enterprise beans.
>
> A word of warning: While EJBObject and EJBHome are interfaces which are
> extended by remote and home interfaces, these terms are also associated with
> conceptual parts of the container system that manage remote and home
> invocations on entity bean instances. Admittedly, it can get a little
> confusing for people new to EJB.
>
>
> --
> Richard Monson-Haefel
> Author of Enterprise JavaBeans, 3rd Edition (O'Reilly 2001)
> Co-Author of Java Message Service (O'Reilly 2000)
> http://www.jMiddleware.com
>
> ===========================================================================
> 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".
>
