Re: [hibernate-dev] PESSIMISTIC_FORCE_INCREMENT lock mode

2017-08-01 Thread Arnold Gálovics
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 clari

Re: [hibernate-dev] PESSIMISTIC_FORCE_INCREMENT lock mode

2017-08-01 Thread 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 acro

Re: [hibernate-dev] PESSIMISTIC_FORCE_INCREMENT lock mode

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

Re: [hibernate-dev] PESSIMISTIC_FORCE_INCREMENT lock mode

2017-08-01 Thread Arnold Gálovics
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 wrote: > In MVCC, shared and exclusive are not as significant as in 2PL > concurrency control which only SQL Server supports by default nowaday

Re: [hibernate-dev] PESSIMISTIC_FORCE_INCREMENT lock mode

2017-07-28 Thread Vlad Mihalcea
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,

Re: [hibernate-dev] PESSIMISTIC_FORCE_INCREMENT lock mode

2017-07-28 Thread Arnold Gálovics
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

Re: [hibernate-dev] PESSIMISTIC_FORCE_INCREMENT lock mode

2017-07-28 Thread Vlad Mihalcea
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 rephrase

Re: [hibernate-dev] PESSIMISTIC_FORCE_INCREMENT lock mode

2017-07-27 Thread Steve Ebersole
Without looking at the complete passage in Vald's article, I will say that the single phrase you pulled out of that context is not accurate IMO On Thu, Jul 27, 2017, 12:01 PM Arnold Gálovics wrote: > Hi all, > > I'm a bit confused with the mentioned lock mode. > > *The doc says the following:* >

[hibernate-dev] PESSIMISTIC_FORCE_INCREMENT lock mode

2017-07-27 Thread Arnold Gálovics
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 versio