Hi,

I have a scenario in which I must atomically update an entity in the database (using JPA). The update can be performed concurrently by multiple threads. What is the best approach? (we don't use optimistic locking).

In a simple approach I'd fetch the entity and update it. But I know that EntityManager.find() can return cached entitites instead of fetching the object from the DB. Will EntityManager.createQuery().getSingleResult() always returns fresh results from the DB? (I can't find the place where it is documented). It looks like using createQuery() with pessimistic locking (select for update) is the solution. Am I right?

Thanks for any help.

From what I understand, you just need to use transactions :-)

Hi Emmanuel,
Thanks for the reply, but I already use transactions around this "critical section" and I experience concurrent modification problems.

If I have two threads, each running in a transaction, fetch the same entry and when the transactions end, both trying to commit the modified object to the DB.

If both threads hold the same Java object it would require using object synchronization (does it work well in jboss?). If they are different objects, how can hibernate detect the concurrent modification and allow the first transaction to commit and the second transaction to fail (we don't use optimistic locks with versioning)?

Genady

First of all, EntityManager is not thread safe and that's on purpose, so don't try and share it across thread. sharing entities objects instances across thread make few sense too.

In understand what you want now, either:
- change the tx isolation level to REPEATABLE_READ
- use em.lock(object, LockMode.READ)

to ensure this constraint.

I use MDBs + ejb3 injections to access entitymanager in different threads.

I will try these techniques. Can you add a few words about how each is implemented? (select for update?)

Thanks!
Genady

Well,
the first one depends on your database
the second one for hibernate, use Select for update or the Db equivalent when loading the entity