[hibernate-dev] PESSIMISTIC_FORCE_INCREMENT lock mode

[Steve Ebersole]

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