[hibernate-dev] JPA2 locking followup...

[Steve Ebersole]

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.  

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 am unclear yet whether PESSIMISTIC_READ will require a NO_WAIT
variant.

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:
> >
> >
> > LockMode.OPTIMISTIC (READ)
> > LockMode.OPTIMISTIC_FORCE_INCREMENT (WRITE)
> > LockMode.PESSIMISTIC_READ
> > LockMode.PESSIMISTIC_WRITE
> > LockMode.PESSIMISTIC_FORCE_INCREMENT
> >
> > 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
> > + LockMode.OPTIMISTIC_FORCE_INCREMENT.
> >
> > 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
-- 
Steve Ebersole <steve at hibernate.org>
Hibernate.org