I applied your suggestions an issued a new commit.
On Thu, Jul 27, 2017 at 5:26 PM, Steve Ebersole wrote:
> I think that is still confusing. I'd suggest something like:
>
>
> When discussing arrays, it is important to understand the distinction
> between SQL array types and Java arrays that ar
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
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
+1 to "clean this up" as it's a major release.
Ideally, would it be possible to already introduce some warning logs
in some later 5.x ?
Thanks,
Sanne
On 27 July 2017 at 15:11, Steve Ebersole wrote:
> Vlad, we have had this discussion like 5 times now ;)
> http://www.mail-archive.com/hibernate-
I agree about the 5.x warnings.
On Fri, Jul 28, 2017, 3:15 AM Sanne Grinovero wrote:
> +1 to "clean this up" as it's a major release.
>
> Ideally, would it be possible to already introduce some warning logs
> in some later 5.x ?
>
> Thanks,
> Sanne
>
>
> On 27 July 2017 at 15:11, Steve Ebersole
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,
