tomee-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Karsten Ohme <>
Subject General approach for locking entities
Date Tue, 02 Feb 2010 16:28:04 GMT

I would like to get some insight into the locking mechanism behind EJB
and problems with them.

I often have the following problem:

Two entities are modified concurrently. This should not happen. I look
for a pattern which makes the live easy.

The solution must work with EJB 3.0. Solutions to solve this which I know:

Pessimistic Locking:

I use SELECT FOR UPDATE on the table during the transaction.

pro: I can be sure that after my transaction is finished, no concurrent
exception is thrown.
con: slows concurrency, is MySQL specific


Optimistic Locking:

I annotate each entity with a @Version column

Pro: concurrency is maximum
Con: I have to run a separate transaction to catch the
OptimisticLockingException and transform it into an application
exception, to let the user know that he has to try again.


In EJB 3.1 there exist singleton beans. So I can serialize method calls,
but what happens if my app is deployed other multiple virtual
machines? So I guess this does not work anymore and I have the same
problem like above.


What happens if the transaction level serializable is specified? Will
any database serialize each request or is only tied to do so, but if it
does not work the transaction is rolled back?


Are there simple solution to my problems?


View raw message