You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomee.apache.org by Karsten Ohme <ko...@mms-dresden.de> on 2010/02/02 17:28:04 UTC
General approach for locking entities
Hi,
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?
BR,
Karsten
Re: General approach for locking entities
Posted by Karsten Ohme <ko...@mms-dresden.de>.
Hi Jean-Louis,
Am 02.02.2010 18:49, schrieb Jean-Louis MONTEIRO:
> Hi,
>
> David is probably the best guy to help on that topic.
> Anyway, there is no absolute rule.
> Pessimistic locking works but is bad for concurrency.
> Optimistic is better for concurrency.
>
>
> Karsten Ohme-3 wrote:
>
>> 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.
>>
>>
> Not required.
> If you wait until the end of the transaction, the caller will receive an
> EJBException not an OptimisticLockingException. According to the spec
> (AFAIK), the container is not required to provide the surrounding exception
> in the root cause.
>
> When using optimistic locking, i just call the em.flush() method in my
> business method (in a stateless for example). So, you are free to catch the
> OptimisticLockingException and throw a business exception (checked and
> declared in the throws - or - Runtime + @ApplicationException).
>
But the Optimistic Locking can only detect changes in tables already
read, right? So if two different transaction write data into one row, I
have no other possibility than pessimistic locking, right?
By the way, the API of the EntityManager is not clear what happens to
merge, if an entity is saved which contains some unique violations. I
handle a EntityExistsException there, but the API does not declare this
Exception to be possible.
What fields of an entity are used to look up the entity and merge
differences? Is it only the ID?
E.g. an application could change the ID now tries to merge it. Is a
EntityNotExistException thrown? Or does the EntityManager keeps track of
the changes and knows that the entity with the now different ID is still
the entity with the different ID before?
WBR,
Karsten
> Hope it helps,
> Jean-Louis
>
>
--
Karsten Ohme
T-Systems Multimedia Solutions GmbH
Portal Technologies, Applications & Appliances
Hausanschrift: Riesaer Strasse 5, 01129 Dresden
Postanschrift: Postfach 10 02 24, 01072 Dresden
Telefon: +49 351 28 20 - 2123
Fax: +49 171 351 28 20 - 5116
E-Mail: karsten.ohme@t-systems.com
Re: General approach for locking entities
Posted by Jean-Louis MONTEIRO <je...@atosorigin.com>.
Hi,
David is probably the best guy to help on that topic.
Anyway, there is no absolute rule.
Pessimistic locking works but is bad for concurrency.
Optimistic is better for concurrency.
Karsten Ohme-3 wrote:
>
> 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.
>
Not required.
If you wait until the end of the transaction, the caller will receive an
EJBException not an OptimisticLockingException. According to the spec
(AFAIK), the container is not required to provide the surrounding exception
in the root cause.
When using optimistic locking, i just call the em.flush() method in my
business method (in a stateless for example). So, you are free to catch the
OptimisticLockingException and throw a business exception (checked and
declared in the throws - or - Runtime + @ApplicationException).
Hope it helps,
Jean-Louis
--
View this message in context: http://n4.nabble.com/General-approach-for-locking-entities-tp1460076p1460160.html
Sent from the OpenEJB User mailing list archive at Nabble.com.