Take the 2-minute tour ×

Unfortunately I'm getting an OptimisticLockException in my code and I'm not sure why. Perhaps there is someone who can help me with an answer to a general question.

Following scenario:

public class MyEntity {
    private Integer id;

    private int version;

    private String value;

public class MyBean {
    private EntityManager em;

    public void test() {

        MyEntity myEntity = em.find(MyEntity.class, 1);


CMT are used. Method test() requires a new transaction.

Now my question: Can method test() throw an OptimisticLockException if there is another thread in another bean using the same persistence context changing my entity before commit although I only use find and don't update anything in my method test()?

share|improve this question
How are you obtaining the EntityManager? They are generally not thread safe - most containers will obtain a new EntityManager behind the proxy EM when starting a transaction, so you might need to check your configuration. –  Chris Jan 17 '13 at 12:50

1 Answer 1

from this blog

JPA Optimistic locking allows anyone to read and update an entity, however a version check is made upon commit and an exception is thrown if the version was updated in the database since the entity was read

So there is no need to do an update to get an OptimisticLockingException. Assume myEntity.getVersion()==1 when you read it. You will have an OptimisticLockingException if, at commit (i.e. when your test() method ends), the actual value in the version column is != 1.

It means that someone updated the entity (in the mean time between the READ and the transaction COMMIT) and so the values you have just read are no more valid at commit time.

share|improve this answer
Thanks for your answer! I guessed it, but wasn't sure. –  Helmut Neubauer Jan 17 '13 at 8:22
The blog post also mentions the additional locking with JPA Entity Locking APIs. I try to find out what's the default. There are some sources saying default is no locking. If I'm now choosing "OPTIMISTIC" there is no difference to using OPTIMISTIC or not? Because the blog says "a version check is made upon commit" always? (I know, the locking is only for my defined entity if I use it in find() method) –  Helmut Neubauer Jan 17 '13 at 8:29
This may depend on providers, but I don't know of any provider that will check the version field for optimistic locking unless there is an update, delete or insert to perform. Find should not cause an optimistic lock exception, unless there are entity changes which get flushed. –  Chris Jan 17 '13 at 12:46
@Chris can you indicate your sources ? Which provider do optimistic check only if an entity has been updated/deleted for a simple transaction ? –  ben75 Jan 17 '13 at 13:43
EclipseLink will also check in a few other cases such as merge, but for the most part, optimistic locking should ensure the write does not go through if the version doesn't match. The point of optimistic locking is that it does allow changes underneath, and only prevents direct conflict. Checking that the version is the same for every managed instance even if they have not changed would kill performance. JPA 2.0 allows passing a pessimistic lock mode to find which will cause a version check and force an OptimisticLockingException, but otherwise find should just return the managed Entity. –  Chris Jan 18 '13 at 13:05

Your Answer


