[hibernate-dev] PESSIMISTIC_FORCE_INCREMENT lock mode

[Arnold Gálovics]

Hey Vlad,

Thanks for the clarification. Do you think it worth mentioning this in the
docs?

Best,
Arnold

On Fri, Jul 28, 2017 at 6:17 PM, Vlad Mihalcea <mihalcea.vlad at gmail.com>
wrote:

> In MVCC, shared and exclusive are not as significant as in 2PL
> concurrency control which only SQL Server supports by default nowadays.
>
> Even if the row is locked in shared or exclusive mode, some other DB will
> still read it. It's just that they will not be able to modify it or
> acquire locks. Here, if you acquire a shared lock, others will still be
> able to acquire a shared lock as well, and that will offer no advantage for
> the PESSIMISTIC_FORCE_INCREMENT over its optimistic alternative.
>
> So, I suppose the lock should always be exclusive so that other lock
> requests are blocked until the lock is released.
>
> Vlad
>
> On Fri, Jul 28, 2017 at 9:35 AM, Arnold Gálovics <galovicsarnold at gmail.com
> > wrote:
>
>> Hey,
>>
>> I'm still a bit uncertain about this, as I only tested this lock mode
>> with H2 which as far as I know is not supporting shared locks, so it will
>> automatically acquire an exclusive lock. That is a possibility why I've
>> seen the FOR UPDATE clause at the end of the SELECT statement.
>>
>> *My question rather is:* what's the intended behavior of this lock mode?
>> Okay, it's a pessimistic lock with incrementing the version number
>> automatically at locking time. What type of lock will it acquire? Shared or
>> exclusive?
>> I think this is important and it should be really mentioned in the
>> Hibernate docs as now it's a bit confusing. The JPA spec is also unclear
>> for me about this lock mode.
>>
>> Thank you guys for helping me out!
>>
>> Best Regards,
>> Arnold
>>
>>
>> On Fri, Jul 28, 2017 at 7:40 AM, Vlad Mihalcea <mihalcea.vlad at gmail.com>
>> wrote:
>>
>>> That's how Hibernate was executing the statements when I wrote the
>>> article.
>>>
>>> I spotted the difference when writing the book, but didn't have time to
>>> update the article.
>>> I changed the SQL output to reflect the current behavior which adds a
>>> FOR UPDATE clause when fetching the entity.
>>>
>>> I also rephrased that sentence since it's no longer relevant to the
>>> current behavior.
>>>
>>> Vlad
>>>
>>> On Thu, Jul 27, 2017 at 4:46 PM, Arnold Gálovics <
>>> galovicsarnold at gmail.com> wrote:
>>>
>>>> Hi all,
>>>>
>>>> I'm a bit confused with the mentioned lock mode.
>>>>
>>>> *The doc says the following:*
>>>> *"The entity is locked pessimistically and its version is incremented
>>>> automatically even if the entity has not changed."*
>>>>
>>>> I'm checking this with an H2 DB and the current behavior is the
>>>> following:
>>>> - the version attribute is incremented in advance, right after fetching
>>>> (I'm using EntityManager#find here, but with lock, it should be the
>>>> same)
>>>> - the original fetching query contains the SELECT ... FOR UPDATE clause
>>>>
>>>> Knowing this, it seems for me that this lock mode involves a DB lock,
>>>> however the doc doesn't say anything about this, especially whether
>>>> it's a
>>>> shared or exclusive lock.
>>>>
>>>> I've checked Vlad's article about this.
>>>> https://vladmihalcea.com/2015/02/16/hibernate-locking-patter
>>>> ns-how-does-pessimistic_force_increment-lock-mode-work/
>>>>
>>>> It says the following: "*The PESSIMISTIC_FORCE_INCREMENT naming might
>>>> lead
>>>> you into thinking that you are using a pessimistic locking strategy,
>>>> while
>>>> in reality this Lock Mode is just an optimistic locking variation."*
>>>>
>>>> So now I'm unsure what this really is.
>>>>
>>>> Could you please briefly describe it to me if I missed something?
>>>>
>>>> Thanks in advance!
>>>>
>>>> Best Regards,
>>>> Arnold
>>>> _______________________________________________
>>>> hibernate-dev mailing list
>>>> hibernate-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>
>>>
>>>
>>
>