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@lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev -- Steve Ebersole <st...@hibernate.org> Hibernate.org _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
