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".
