For the sake of clarification, say I have an Account entity bean, which has a collection of EmailAddress entity beans (1 to many container managed relationship).
A client calls a method getAcctInformation() on a session bean. This method looks up the Account bean, and iterates over the EmailAddress beans (retrieving the information to send back to the client).
A client then calls a method updateEmailInfo() on a session bean, to update one of the EmailAddress records retrieved above. This method looks up a particular EmailAddress bean (directly, via a finder), and modifies its state. This is persisted to the database with no problems.
Now, when the client calls getAcctInformation() again, it still gives back the old information for that particular EmailAddress (not what is in the database).
Is there a way to invalidate the old bean instance? Why does it not stay in sync with the update? Is there a difference in caching when using CMR and not using CMR?
If anyone has an idea of things I might be able to investigate in order to further debug this issue, it would be greatly appreciated. Thanks.
(Note: I'm not using clustering.)
I did find a workaround for this problem (see below), but I still have no idea why the original problem would be happening, or what the root of the problem really is.
One other bit of information that might be helpful in resolving: if I restart the server, the problem goes away. In other words, the problem only seems to occur if the data in question was created during the same server session (where "server session" = a particular run of the app server, between restarts).
For the particular bean which was not staying in sync, I configured it in jboss.xml to use the default "Instance Per Transaction CMP 2.x EntityBean" configuration (which uses commit-option C). This ensures the entity instance stays up-to-date. [See the Wiki at http://www.jboss.org/wiki/Wiki.jsp?page=CMPCaching for details about instance caching and commit options.]
It would be nice to keep commit-option A, though.
If anyone knows of a better solution, please let me know. It seems a shame to have to resort to commit-option C in this case.