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.v...@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 <galovicsarn...@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.v...@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 < >>> galovicsarn...@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@lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>> >>> >>> >> > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
