JPA locking

[cowwoc]

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

[James Sutherland]

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

[cowwoc]

James,

How do you deal with high-contention applications where optimistic locking is going to run into collisions with high frequency?

As for recovering from OptimisticLockException, I'll give you a better use-case. Say you have an online shopping cart application where each product has X inventory items and users should be able to place an order so long as there is at least one item left. The problem is that between the time the user adds the item to the cart to the moment he completes the order form at least one item might have already gotten sold. Now, you want to use optimistic locking over the Product but you don't care if the inventory count decreased so long as there is at least one left. How do you implement this? And more generally, how do you implement "decrement" in a high-contention scenario without lost updates? That is, if 10 people order the same item at the same time, I don't want to ask 9 people to repeat the order process because of a OptimisticLockException.

Thanks,
Gili


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

[Andreas König-2]

Hey there...

I think, I didn't really get the expression language yet.
I have two classes:

Offer and Publication

An Offer can have multiple publications, from which only the youngest is
interesting for me.
For architectural reasons, the offer-object has no reference to the
publication(s). Only the publication has a refence to the object.

How do I get an SQL like this with expression language?

SELECT offer.id,
        publication.id
FROM
        Offer offer
LEFT OUTER JOIN PUBLICATION pub ON pub.offer_id = offer.id
WHERE NOT EXISTS (not so important subquery)


I tried different ExpressionBuilders, but nothing seemed to work. The
result was always wrong way around: pub left outer join offer.

Thanx in advance!

Andreas




--
Andreas König
Developer

andreas.koenig@...

serie a logistics solutions AG
Hülchrather Straße 15
D-50670 Köln

T [phone]
F [phone]

Vorstand: Axel Löhr, Erwin Soldo
Aufsichtsrat: Adam Musialik (Vors.), Fritz Pleitgen, Hans Jörg Klofat

Amtsgericht Köln HRB 61725

www.serie-a.de


_______________________________________________
eclipselink-users mailing list
eclipselink-users@...
https://dev.eclipse.org/mailman/listinfo/eclipselink-users

[tware]

Hi Andreas,

   What code do you use to build your query?  What is the resulting SQL?

   I would expect that you could add a joined expression to your query using
Expression.getAllowingNull(<attribute>)

-Tom

Andreas König wrote:

> Hey there...
>
> I think, I didn't really get the expression language yet.
> I have two classes:
>
> Offer and Publication
>
> An Offer can have multiple publications, from which only the youngest is
> interesting for me.
> For architectural reasons, the offer-object has no reference to the
> publication(s). Only the publication has a refence to the object.
>
> How do I get an SQL like this with expression language?
>
> SELECT     offer.id,
>     publication.id
> FROM
>     Offer offer
> LEFT OUTER JOIN PUBLICATION pub ON pub.offer_id = offer.id
> WHERE NOT EXISTS (not so important subquery)
>
>
> I tried different ExpressionBuilders, but nothing seemed to work. The
> result was always wrong way around: pub left outer join offer.
>
> Thanx in advance!
>
> Andreas
>
>
>
>

_______________________________________________
eclipselink-users mailing list
eclipselink-users@...
https://dev.eclipse.org/mailman/listinfo/eclipselink-users

[James Sutherland]

There are definitely cases when pessimistic locking makes sense, such as high-contention applications.  Normally it is used in server-side locking, as you rarely desire to hold a pessimistic lock while waiting for a response from a web client.  In some cases you can also use optimistic locking with a retry block.

EclipseLink supports pessimistic locking through the query hint, "eclipselink.pessimistic-lock"="Lock".



James,

How do you deal with high-contention applications where optimistic locking is going to run into collisions with high frequency?

As for recovering from OptimisticLockException, I'll give you a better use-case. Say you have an online shopping cart application where each product has X inventory items and users should be able to place an order so long as there is at least one item left. The problem is that between the time the user adds the item to the cart to the moment he completes the order form at least one item might have already gotten sold. Now, you want to use optimistic locking over the Product but you don't care if the inventory count decreased so long as there is at least one left. How do you implement this? And more generally, how do you implement "decrement" in a high-contention scenario without lost updates? That is, if 10 people order the same item at the same time, I don't want to ask 9 people to repeat the order process because of a OptimisticLockException.

Thanks,
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

[cowwoc]

James,

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

Thank you,
Gili



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