I'll tell you how I implement that in Castor right now (Castor is a CMP
engine and Java-SQL-XML-LDAP mapping tool).
As far as Castor is concerned container B may also be a legacy
application, a Servlet or anything else that does a direct database
access not going through the persistence layer. So changes happening
from B must be reflected in A, whether or not you have some mechanism
there than can synchronize these changes.
If you build on this assumption you can mix EJB, Servlets, direct JDBC,
C++, Perl, whatever works for you. And you only need one layer to
implement locking, the database itself, which is already given.
More importantly, you can mix entity and session bean access. What if B
is a session bean rather than an entity bean. You lose the
synchronization model.
At stage 3 when A gets another request, A is going to do one of two
things depending on the locking model:
1. Pessimitic -- You assume that concurrent access will happen from the
outside, A will always attempt to synchronize with the database. Right
now that means A will reload the object image into memory. But most
databases have a mechanism to allow you to check if A has the most
recent version, in Oracle through RAWID, in Sybase/SQL-Server through
Timestamp.
2. Optimistic -- You assume that concurrent access to the same object is
very rare, so A works from the cache copy assuming 99% of the cases it
has an accurate copy. When A is about to persist, dirty checking occurs
prior to saving making sure A indeed had the most accurate copy.
These two models work very well with RDBMS access for a variety of
reason. For example, imagine a scenario where A and B are running
concurrently. A reads something, B reads something, B stores a change
and then A stores a change. There is no value in updating A's cache in
the middle of the transaction, since that would lead to inconsistency.
A's update should either succeed or fail, and in this case fail because
B was there first.
In pessimistic locking, A acquires a write lock preventing B from
accessing the database until A commits. In optimistic locking, A and B
race to see which one gets to do the update first, B wins, A fails in
the dirty checking and the transaction is rolledback.
This is exactly how databases maintain concurrency internally through
the different isolation levels.
The beauty of this approach, as I said before, is that B can be
anything. It can be a session bean, it can be an EJB server from a
different vendor, it can be something other than EJB. The notification
solution only works if both A and B are entity beans running in an EJB
server from the same vendor.
arkin
> The specific scenario I'm thinking of is this:
>
> 1. Container A instantiates an entity bean with a PK of 26. This
> entity is not in Container A's cache (in its VM), so it reads
> it from the database and caches it. The entity is used, and is
> eventually passivated.
>
> 2. Container B instantiates the same entity bean (PK 26). It's
> not in its cache, so it reads it from the database. After
> updating some fields in the entity, the entity is stored back
> to the database.
>
> 3. Container A gets another request to use the entity (PK 26).
> It finds the entity in its cache, and uses the cached entity.
> But this copy is no longer up to date, because it doesn't
> reflect the changes made through container B.
>
> Obviously, something needed to happen after step 2 to cause the
> entity in container A's cache to be invalidated so that it will
> refresh it from the database on the next access. If the cluster
> is the only thing that will be accessing the entity, then these
> notifications can be generated from container to container,
> perhaps using JMS. If arbitrary apps can update the database,
> then the notification would have to come from the database,
> perhaps via triggers or some such.
>
> Is there any CMP product on the market that handles this scenario
> (assuming that the cluster can own the database for now)?
>
> Thanks,
> -Paul Hodgetts
>
> ===========================================================================
> 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".
--
----------------------------------------------------------------------
Assaf Arkin www.exoffice.com
CTO, Exoffice Technologies, Inc. www.exolab.org
===========================================================================
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".
