One of the advantages given for using Entity EJBs is that they are cached by the application server. So, I assume that if a user tries to read the same data previously read by another user then the cached version gets returned.

What happens when the data is updated by a different process entirely (e.g. some legacy system)? What will cause the cached beans to be invalidated?

Thanks in advance,
John

In weblogic you can specify db-is-shared attribute for an entity bean. Than server will reload the bean every time a TX begins.

There are different caching strategies based on ejb spec and vendor specific caching implementations.

Check out the ejb spec on COMMIT OPTIONS A,B,C and depending on the vendor these behave slightly different implementations of concurrency strategies from serialization of calls to first-out-last-in concurency.

Mike

<John>
What happens when the data is updated by a different process entirely (e.g. some legacy system)? What will cause the cached beans to be invalidated?
<John>

Commit Option B or C can be used for such a system.
Option B only the PKs are cached and ejbLoad is called at TX start.

Caching provides a benefit only when the appserver has the only access to update the DB such as Commit Option A or for read-only data that infrequently changes or when non transactional data is timed out.


Mike