Section 3.4 talks about pessimistic locking in general and says
"Applications that perfer the use of pessimistic locking may require
that database isolation levels higher than read-commited be in effect.
The configuration of the setting of such database isolation levels,
however,is outside the scope of this specification."
And then the section that discusses the lock() call itself is 3.4.3.
-Scott
On Fri, 2006-03-03 at 14:45, Marina Vatkina wrote:
> Tom, Gordon,
>
> Is this functionality in?
>
> Scott,
>
> Which exactly section still says that it's out of the scope?
>
> thanks,
> -marina
>
> -------- Original Message --------
>
>
> Is there any way to accomplish pessimistic locking in 3.0 persistence?
> The spec says such work in out of scope of the spec, but then in the
> discussion of the lock manager, it says if I call lock(entity,
> LockModeType.READ) that is will give me repeatable-read semantics (which
> is what I want) and generally do so by acquiring a lock on the
> underlying database row (which to my mind is pessimistic locking).
>
> But I've tried calling the lock() method, and it seems to have no
> effect. Specifically, I'd like to have pessimistic locking on an
> inventory object, which is a one-to-one relationship to an assembly, so
> I do this:
>
> Assembly a = em.find(Assembly.class, pk);
> Inventory i = a.getInventory();
> em.lock(i, LockModeType.READ);
>
> The lock call doesn't issue any calls at all to the database (so no row
> lock); maybe the VM cache is just supposed to lock it and isn't. Or
> maybe I just have it wrong.
>
> The standard optimistic locking works, but I'm afraid there will be too
> many OptimisticConcurrencyExceptions in the app that way.
>
> -Scott
>
>