[hibernate-dev] PESSIMISTIC_FORCE_INCREMENT lock mode

Vlad Mihalcea mihalcea.vlad at gmail.com
Tue Aug 1 09:20:24 EDT 2017


Sure. Send me a Pull Request and I'll integrate it.

Vlad

On Tue, Aug 1, 2017 at 2:29 PM, Arnold Gálovics <galovicsarnold at gmail.com>
wrote:

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


More information about the hibernate-dev mailing list