Hello,
I have a question regarding when an optimistic lock check is performed. As per
the EJB 3.0 specification, when we attempt to merge a detatched entity that has
a stale version, the exception is thrown. However, consider the following case:
| @TransactionAttribute(value = TransactionAttributeType.REQUIRED)
| public void versionTest(Long id, String value) {
| DbSample sample = entityManager.find(DbSample.class, id);
| id.setValue(value);
| entityManager.flush();
| }
|
(where DbSample is an entity bean with a @Version property)
Now, consider the following set of events:
Client A calls versionTest(1, "ClientA") and a breakpoint is set after the
sample is fetched
Client B calls versionTest(1, "ClientB") and a breakpoint is set after the
sample is fetched
Client B is allowed to continue its transaction and commit.
Client A is then allowed to continue its transaction and commit.
Instead of an optimistic lock exception being thrown, the result is that the
value "ClientB" is saved to the database, and the version is incremented by 1.
The ClientA method call seems to be silently ignored despite committing last.
Is this the expected behaviour? The EJB 3.0 specification states that the
optimistic lock check is supposed to be done at transaction commit time. This
seems like a bug. Thoughts?
-Sean
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3957902#3957902
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3957902
_______________________________________________
jboss-user mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/jboss-user
