[hibernate-dev] JPA2 locking followup...

[Scott Marlow]

Initial support for locking is checked in via HHH-4546.


On 10/30/2009 03:42 PM, Scott Marlow wrote:
> 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 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
>>>
>>>        
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>