[hibernate-dev] PESSIMISTIC_FORCE_INCREMENT lock mode

[Vlad Mihalcea]

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
>>>
>>
>>
>