I assume that the isolation levels you are referring to are used by the
WebLogic container to configure the JDBC connection to indicate which
isolation level to use while accessing the database. This is completely
consistent with what I said earlier, as the reasonability of concurrency
is pushed to the database.
Ashutosh wrote:
> 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 AMSubject: Re: Concurrency in Entity
> beans > Bill Leonard wrote:
> >
> > > > 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".
>
> >
--
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".
