Re: [eclipselink-users] JPA locking

[James Sutherland <jamesssss@xxxxxxxxx>]

There are definitely cases when pessimistic locking makes sense, such as
high-contention applications.  Normally it is used in server-side locking,
as you rarely desire to hold a pessimistic lock while waiting for a response
from a web client.  In some cases you can also use optimistic locking with a
retry block.

EclipseLink supports pessimistic locking through the query hint,
"eclipselink.pessimistic-lock"="Lock".



cowwoc wrote:
> 
> James,
> 
> How do you deal with high-contention applications where optimistic locking
> is going to run into collisions with high frequency?
> 
> As for recovering from OptimisticLockException, I'll give you a better
> use-case. Say you have an online shopping cart application where each
> product has X inventory items and users should be able to place an order
> so long as there is at least one item left. The problem is that between
> the time the user adds the item to the cart to the moment he completes the
> order form at least one item might have already gotten sold. Now, you want
> to use optimistic locking over the Product but you don't care if the
> inventory count decreased so long as there is at least one left. How do
> you implement this? And more generally, how do you implement "decrement"
> in a high-contention scenario without lost updates? That is, if 10 people
> order the same item at the same time, I don't want to ask 9 people to
> repeat the order process because of a OptimisticLockException.
> 
> Thanks,
> Gili
> 
> 
> James Sutherland wrote:
>> 
>> I'm not sure where the lock exception would occur in your use case.  But
>> in general, whether something is valid or not depends on the application
>> and use case, for some applications no locking at all is perfectly valid.
>> 
>> In JPA there is no pessimistic locking at all, so there is no correct way
>> to use pessimistic locking.  The lock() API acquires an optimistic lock,
>> not a pessimistic lock.  It means that the version will be checked, or
>> updated on commit, it does not matter when it is called in the
>> transaction, as the check occurs on commit.  The link gives a hack to
>> attempt to simulate pessimistic locking using an update, it may work in
>> some cases.  In EclipseLink you can just use the query hint to acquire a
>> pessimistic lock.
>> 
>> 
>> 
>> cowwoc wrote:
>>> 
>>> Hi James,
>>> 
>>> I've been reading http://en.wikibooks.org/wiki/Java_Persistence/Locking
>>> and it's a godsend... I've been looking for this kind of
>>> straight-forward discussion for a long time now. So first of all, thank
>>> you for the article, I really appreciate it! :)
>>> 
>>> Now, as for
>>> http://en.wikibooks.org/wiki/Java_Persistence/Locking#Handling_optimistic_lock_exceptions
>>> I was wondering, is it reasonable to automate handling of the
>>> OptimisticLockException in the following case?
>>> 
>>> - Server holds a collection of images
>>> - Client requests a random image
>>> - Server queries the total number of images
>>> - Server selects a random number
>>> - Server queries image at index X but it turns out that the image was
>>> deleted since the previous query
>>> 
>>> In such a case, the client really did nothing wrong. From it's point of
>>> view the request is still valid (no stale data, nothing that would cause
>>> it to change the request in any way). As such, would it be reasonable
>>> for the server to automatically replay the request and select another
>>> image randomly?
>>> 
>>> Secondly,
>>> http://www.funofmath.com/weblog/2008/03/implementation-of-pessimistic-locking.html
>>> indicates that the only way to lock pessimisticly (without race
>>> conditions) is by doing:
>>> 
>>>     Object entity = entityManager.getReference(clazz, id);
>>>     entityManager.lock(entity, LockMode);
>>> 
>>> I was wondering whether this is portable across all JPA vendors and
>>> whether you could please add this to the Wiki page? Also, you probably
>>> want to revise
>>> http://en.wikibooks.org/wiki/Java_Persistence/Locking#Example_of_Using_the_Lock_API
>>> as it seems to be open to a race condition (you should be locking the
>>> Manager before reading his salary, not the other way around.)
>>> 
>>> Thank you,
>>> Gili
>>> 
>> 
>> 
> 
> 


-----
---
http://wiki.eclipse.org/User:James.sutherland.oracle.com James Sutherland 
http://www.eclipse.org/eclipselink/
 EclipseLink ,  http://www.oracle.com/technology/products/ias/toplink/
TopLink 
Wiki:  http://wiki.eclipse.org/EclipseLink EclipseLink , 
http://wiki.oracle.com/page/TopLink TopLink 
Forums:  http://forums.oracle.com/forums/forum.jspa?forumID=48 TopLink , 
http://www.nabble.com/EclipseLink-f26430.html EclipseLink 
Book:  http://en.wikibooks.org/wiki/Java_Persistence Java Persistence 
-- 
View this message in context: http://www.nabble.com/JPA-locking-tp19525631p19552752.html
Sent from the EclipseLink - Users mailing list archive at Nabble.com.