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