Re: [eclipselink-users] JPA locking

[cowwoc <cowwoc@xxxxxxxxxxxxxxxx>]

James,

Can you please comment on this thread?
http://forums.java.net/jive/thread.jspa?messageID=315838

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

-- 
View this message in context: http://www.nabble.com/JPA-locking-tp19525631p20424828.html
Sent from the EclipseLink - Users mailing list archive at Nabble.com.