Skip to main content

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


Can you please comment on this thread?

Thank you,

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

View this message in context:
Sent from the EclipseLink - Users mailing list archive at

Back to the top