[hibernate-dev] JPA2 locking followup...

Scott Marlow smarlow at redhat.com
Fri Oct 30 15:42:21 EDT 2009

On 10/30/2009 02:08 PM, Steve Ebersole wrote:
> As I said on IRC, my belief is that we should expand this set of lock
> modes specifically to include NO_WAIT variants.  Its really just a
> question of for which modes it makes sense.  The spec says
> "javax.persistence.lock.timeout" is "defined by this specification for
> use in pessimistic locking" so obviously OPTIMISTIC and
> OPTIMISTIC_FORCE_INCREMENT are fine by themselves.

This is probably cleaner than the JPA2 overloading of timeout property 
(value of zero meaning NO_WAIT).

> I don't think PESSIMISTIC_FORCE_INCREMENT needs a NO_WAIT variant, even
> if we were to support using this mode on non-versioned entities.

I agree.

> I am unclear yet whether PESSIMISTIC_READ will require a NO_WAIT
> variant.

If PESSIMISTIC_READ is implemented with PESSIMISTIC_WRITE support, I 
would think yes.

> Conversely for "with wait" semantics we will need to add support for the
> lock acquisition timeout.
> On Fri, 2009-10-30 at 13:49 -0400, Scott Marlow wrote:
>> How should we handle the _NOWAIT variants for the three Pessimistic
>> modes?  The JPA2 style is to use the "javax.persistence.lock.timeout
>> (time in milliseconds, with 0 meaning no wait).
>> Internally, we need Hibernate core to support the three pessimistic lock
>> modes (read, write, force_increment) with a JPA2 style timeout option.
>> Since, we need to support JPA2 timeout per requested lock, we might want
>> to support _NOWAIT via the same mechanism as we use for timeout.
>> On 10/30/2009 09:18 AM, Scott Marlow wrote:
>>> For JPA2 support, I propose that Hibernate LockMode support the
>>> following equivalents of JPA2 LockModeType locks:
>>> Hibernate already supports NONE, so that doesn't need to be added.  JPA2
>>> defaults to LockModeType NONE.
>>> JPA1 READ + WRITE will be supported respectively via LockMode.OPTIMISTIC
>>> With this change, Hibernate (native (better term?)) applications would
>>> be able to request JPA2 like locks.  This also means that JPA2
>>> applications running with the Hibernate Entity Manager, will see similar
>>> locking behavior as native applications.
>>> Pros:
>>> - Application developers will have a consistent set of locking options
>>> in their JPA2 based applications and native Hibernate applications.
>>> - This helps the application developer to prepare their native Hibernate
>>> application to migrate to JPA2.
>>> Cons:
>>> - This ties Hibernate core locking internals to the JPA2 specification.
>>> As JPA continues to evolve, Hibernate core should follow in lockstep.
>>> Although, that is not a hard requirement.
>>> - An alternative would be introducing low level locking primitives that
>>> could be combined to support JPA2 style locks.  I can explore this path
>>> if there is strong push back to the above proposal.
>>> Comments?
>>> Scott
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev

More information about the hibernate-dev mailing list