Sure. Send me a Pull Request and I'll integrate it. Vlad
On Tue, Aug 1, 2017 at 2:29 PM, Arnold Gálovics <galovicsarn...@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.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
