Ok, it's a Java EE 5 application, all components running in the same EAR on glassfish. The frontend is a JSF webapp, which loads objects via accessing a session bean. Let's call A the class, where optimistic locking works as expected, and B the class that produces stale data. I have ABean and BBean, they offer a getA(PrimaryKeyA pk) and getB(PrimaryKeyB pk) method respectively. Additionally, there are methods updateA(A obj) and updateB(B obj) methods.
The webapp has a controller, which gets the ABean and BBean injected via annotation. The getA or getB method is called, the user manipulates the objects in a form and posts them back, then the controller calls updateA or updateB. Absolutely identical architecture except that BBean is @Remote and ABean is @Local, both are stateless. Both have an appropriate EntityManager, which is injected via annotation @PersistenceContext.
In the case of A the external modifications happen via a nightly batch run, where older programs update the database directly. So I could run a batch job in the morning, that simply closes the A's EntityManager, however, A is working anyway. B is more of a problem, because it is updated continually during the day - not a lot of rows affected, though. Maybe ten per day or so, these are manual updates triggered by a user using an older GUI.
I am loading A and B directly, as should be apparent from this description. The stale data I am seeing is whenever I make a subsequent JPA query, after the OptimisticLockException was thrown. The subsequent query gets stale data from the cache. Only a refresh() will load the current data from the database.
Ulrich
[Message sent by forum member 'ulim' (ulim)]
http://forums.java.net/jive/thread.jspa?messageID=242403