When is the optimistic lock check done?

[sdawson]

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