> [mailto:[EMAIL PROTECTED]]On Behalf Of Evan Ireland
> Subject: Re: keeping entity beans in sync with db
> Regarding Borland AppServer, ask them. For EAServer, the answer is Yes.
With regard to the Borland AppServer, calling a business
method on the remote interface of an entity bean whose
instance has been removed from the database (say by a legacy
app) will cause a "java.rmi.NoSuchObjectException" exception
to be thrown.
This is as per the EJB 1.1 spec which states - Section 8.3.3:
<spec>
After an entity object has been removed, subsequent attempts
to access the entity object by a client result in the
java.rmi.NoSuchObjectException.
</spec>
> <vendor>
>
> With Sybase EAServer 4.0 (release date 17th Sept), you can during
> deployment request that external database changes be notified to
> the Object Cache.
>
> </vendor>
Evan, with regard to your above statement, I have cut and pasted
something from our faqs regarding the above statement. Comments?
-krish
<vendor>
Possibility 1:
If you use Option A, you'll be caching the state of EJBs in the
container after a transaction completes and when that same EJB
becomes involved in another transaction, you'll reuse the state
without going to the database. Now, let's say there's a legacy
application making changes to the data in the database--without
the container knowing about it. This is potentially a common case.
What some Containers could do is, while the cached EJBs were
NOT involved in a transaction, a background thread in the
container would walk through the list of cached EJBs
(periodically) and check if their data was changed in the
database and, if so, refresh them.
Unfortunately, this approach is broken. Say then, at time t1,
the container verified that the database and cache were in sync.
Then say at t2, the container starts a new transaction and uses
the up-to-date cached state. Also, let's say at t3, a legacy
application changes the data in the database. The problem occurs
if t3 comes between t1 and t2. The container thinks the cache is
up-to-date and in fact it is not. When t3 falls between t1 and t2,
the legacy application's changes are potentially wiped out.
The only way to solve this problem is to check the database before
starting the transaction. This is exactly what we were trying to
avoid in the first place!
Unfortunately, ACID properties are nasty. You just can't cheat!
So again, any vendor that claims they solve this problem is either:
- Lying
- Doing something incorrect
Persistence's application server claims to use optimistic
concurrency control attributes (OCAs) to detect the case
where t3 fell in between t1 and t2, in which case the
database would have a higher OCA value than the cached
EJB state, and the EJB transaction would either fail with
a special concurrency-control exception, or wipe out the legacy
application's changes (configurable).
Possibility 2:
The only way to do this correctly is to run triggers in the
database within the current transaction (technically in the
before-completion phase of the transaction). This seems
extremely painful (and proprietary). How does the trigger
get associated with the current JTS/OTS-managed
transaction? Just updating the caches after the database has
changed introduces (albeit transient) inconsistencies in the
data, which obviously violates any kind of correctness.
</vendor>
===========================================================================
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".
