|Re: [eclipselink-users] JPA locking|
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.
Back to the top