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