On 20 oct. 09, at 15:45, Scott Marlow wrote:
On 10/16/2009 03:40 PM, Emmanuel Bernard wrote:
> When I discussed that with Gavin, I believe this idea is that you can
> implement the optimistic locking in the following way:
> - when locking an object read the version number (or if already
> loaded keep this one - not sure about that detail)
> - when flushing or right before commit, read the version number again
> from the database and compare.
> If they are different => exception
>
> A provider may but is not forced to acquire the lock
>
> Note that today we implement Optimistic in a pessimistic way (ie que
> acquire the DB lock right away).
>
> So there are three levels really
> no lock => we check versions upon UPDATE operations
> optimistic => we check versions on reads as well and verify
> consistency
> pessimistic => we lock at the DB level.
Currently, the Hibernate EM depends on Hibernate core for locking
(as it
should). I have a few questions about how achieve the above locking
with Hibernate core and about what changes are needed.
The JPA 2 locking operations that we need support for are:
OPTIMISTIC (equal to READ) - should read the version initially and
confirm that it hasn't changed at transaction commit time. We should
throw OptimisticLockException if the version has changed. I think
that
we need a new LockMode for this (similar to LockMode.READ).
correct.
For
extended persistence context (meaning that the duration is beyond the
end of transaction), I think that we use the entity value from the
extended persistence context as is but should still confirm that it
hasn't changed at commit time (optimistically assume that it hasn't
changed initially).
I am not sure where you are getting at, I don't see the difference
between the extended PC and the classical PC in this case.
OPTIMISTIC_FORCE_INCREMENT (equal to WRITE) - should read the version
initially. At transaction commit time, confirm that the version
hasn't
changed as we increment it via update. We should throw
OptimisticLockException if the version has changed. I think that we
need a new LockMode for this (similar to LockMode.READ and
LockMode.FORCE). Same rules as above for extended persistence
context.
yes same logic as above.
PESSIMISTIC_WRITE - Should obtain a database write lock on the entity.
Hibernate LockMode.Upgrade could be used for this on dialects that
support it. For dialects that don't support LockMode.Upgrade, a
PessimisticLockException should be thrown.
PESSIMISTIC_READ - Should obtain a shared database read lock on the
entity (for the duration of the database transaction). How should we
support this? The JPA 2 specification allows the PESSIMISTIC_WRITE
behavior to be used.
Ideally we should use:
- nothing but reading if we are in repeatable read
- a shared lock on databases that do support the contract
- fall back to P_WRITE if it does not.
PESSIMISTIC_FORCE_INCREMENT - Same as PESSIMISTIC_READ but with an
increment version at transaction commit time (even if entity isn't
updated). I think that we need a new LockMode for this. We need a
way
to throw an exception if not supported.
No it is the same as PESS_WRITE but with a version increment because
the spec describes possible escalations as P_R < P_W < P_FI
So I think it's mappable to LockMode.FORCE
For pessimistic locks, only lock element collections and relationships
owned by the entity, if property javax.persistence.lock.scope is set
to
"PessimisticLockScope.EXTENDED".
Assuming we do the above, we need to release note that READ/WRITE
locks
are obtained in optimistic manner which is a change from our JPA 1
support.
I don't understand.
Comments?
Any volunteers willing to help with JPA 2 implementation (coding,
testing, moral support) are welcome to join in.:-)
Scott
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev