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.