[eclipselink-users] JPA locking

[cowwoc <cowwoc@xxxxxxxxxxxxxxxx>]

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