> 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.
In my described case there isn't an exception, because Node B make an UPDATE query where the "where clause" can't identify any row, So the query go on and no rows was affected.
>It would then be up to the application to decide if it
> should refresh and retry the changes.
If I call an entityManager refresh, it raise an exception because find the entity 'E' in persistence context but can't find it in a db in order to make synchronization.
> 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.
I already use TopLink-refresh hint
> 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.
I must see it!! thanks
> In the end, only pessimistic locking can prevent
> stale data, so I'd strongly advice using optimistic
> locking if you are not already.
I already use toplink-pessimistic exception, but in this case the problem isn't "select for update" locking. The problem is in merging a deleted data.
> Best Regards,
> Chris
Many thanks for your contribuition
[Message sent by forum member 'peppeme' (peppeme)]
http://forums.java.net/jive/thread.jspa?messageID=266414