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- patterns-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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

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(a)gmail.com&gt; 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(a)gmail.com&gt; 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(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > >

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(a)gmail.com&gt; 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(a)gmail.com&gt; 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(a)gmail.com&gt; >> 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(a)gmail.com&gt; 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(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>> >>> >>> >> >

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(a)gmail.com&gt; 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(a)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(a)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(a)gmail.com&gt; 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(a)gmail.com&gt; > >>> 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(a)gmail.com&gt; 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(a)lists.jboss.org > >>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev > >>>>> > >>>> > >>>> > >>> > >> > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev >