Skip to main content

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

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-tp19525631p19535438.html
Sent from the EclipseLink - Users mailing list archive at Nabble.com.



Back to the top