We encounter the same problem with toplink-essentials.
Architecture:
Container managed persistence and container managed transactions using JTA.
The EntityManager is injected in a Stateless Session Bean. During the execution of the business method/transaction, the same EntityManager is used, it is contained in a ThreadLocal variable to provide easy access to it.
The Stateless Session Bean is the only way to update data in the database.
The session bean is used by the web container and by a Java EE client application (batch processing).
When we first encountered the stale object problem, we could solve it by adding the following rule to persistence.xml:
<property name="toplink.cache.type.default" value="NONE" />
This solved the stale object problem, or so we thought...
It seems that we still have the stale object problem (probably a reference(collection) that is stale). We are still tracing to find the exact cause - we cannot always reproduce the problem.
We are not using any toplink specific query hints to refresh the objects. That should not be needed - even if the same objects are loaded and modified in subsequent calls to a business method - since the default PersistenceContextType is TRANSACTION, and not EXTENDED.
The main difference with the problem stated in this thread is that glassfish is used. Our application runs on OC4J 10.1.3.1 with toplink-essentials. (The problem is not cluster related).
[Message sent by forum member 'koenhautekeete' (koenhautekeete)]
http://forums.java.net/jive/thread.jspa?messageID=209808