tomee-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Karsten Ohme <...@mms-dresden.de>
Subject Re: General approach for locking entities
Date Wed, 03 Feb 2010 17:17:43 GMT
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 


Mime
View raw message