Hello,
I'm not sure what you want to happen in this situation, since really this is a concurrent modification where Node B is working on stale data. The fact that it is happening in a different persistence context is irrelevant, as it can happen on the same node in a multi-threaded environment. Depending on how the application is getting and merging instance 'E', the provider should attempt an update statement, causing an exception to be thrown back to the application indicating a problem. It would then be up to the application to decide if it should refresh and retry the changes.
To limit the amount of stale data, you might try using the refresh query hint before sensitive transactions and to set the caching levels appropriately to match the applications usage. TopLink and EclipseLink (which will be the default JPA 2.0 provider) also have more advanced features such as cache coordination and cache invalidation that might help.
In the end, only pessimistic locking can prevent stale data, so I'd strongly advice using optimistic locking if you are not already.
Best Regards,
Chris
[Message sent by forum member 'chris_delahunt' (chris_delahunt)]
http://forums.java.net/jive/thread.jspa?messageID=266411