Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipselink-users] JPA locking

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,

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
>>> 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
>>> 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,
>>> 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
>>> 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

--- James Sutherland
 EclipseLink ,
Wiki: EclipseLink , TopLink 
Forums: TopLink , EclipseLink 
Book: Java Persistence 
View this message in context:
Sent from the EclipseLink - Users mailing list archive at

Back to the top