[hibernate-dev] PESSIMISTIC_FORCE_INCREMENT lock mode

Wed Aug 2 02:53:00 EDT 2017

Hey Steve,

Okay, I'd really appreciate an "understandable" documentation regarding
this. However, I feel that this needs a bit of work to introduce a clean
description about the different type of LockModeTypes, as now the doc
states explicit/shared locks.
If you agree, I'd create a ticket to clarify this and someone (maybe I, if
the time lets me) could take it up in the future.

Best Regards,
Arnold

On Tue, Aug 1, 2017 at 5:20 PM, Steve Ebersole <steve at hibernate.org> wrote:

> Actually the spec is quite specific on the expected behavior of these lock
> modes, although it is very detailed and verbose almost to the point of
> being unclear.
>
> Also it is confusing to think of this in terms of generalized concepts
> such as "exclusive" versus "non-exclusive".  Database locking across
> vendors is not so binary.  Again, the JPA spec sets forth the expected
> outcomes.
>
> If these outcomes can be (very) succinctly described then it could be a
> good idea to cover them in the docs.  Otherwise, I think we should just
> point to the JPA spec.  But if we do add it to the docs, we should avoid
> explaining this via terms like "exclusive", etc. - just describe the
> outcomes/phenomena.
>
> On Tue, Aug 1, 2017 at 9:23 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
> wrote:
>
>> 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
>> >>>>>
>> >>>>
>> >>>>
>> >>>
>> >>
>> >
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>