HHH-15541 Possible carrier thread pinning synchronized blocks migrated to ReentrantLock

[hurelhuyag]

https://hibernate.atlassian.net/browse/HHH-15541

[hibernate-github-bot]

Thanks for your pull request!

This pull request appears to follow the contribution rules.

› This message was automatically generated.

[Sanne]

Good idea, thanks @hurelhuyag !

[beikov]

Do you accept the following terms?

---

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license
and can be relicensed under the terms of the LGPL v2.1 license in the future at the maintainers' discretion.
For more information on licensing, please check here.

---

[yrodiere]

Do you accept the following terms?

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license and can be relicensed under the terms of the LGPL v2.1 license in the future at the maintainers' discretion. For more information on licensing, please check here.

Bump @hurelhuyag :)

[hurelhuyag]

Yes, I accept the terms

[yrodiere]

Thanks! I rebased to launch CI, since it's been a while. Let's merge if builds pass.

[yrodiere]

Looks like there are formatting issues:

Missing newline in /hibernate-core/src/main/java/org/hibernate/service/internal/AbstractServiceRegistryImpl.java
226: 		} finally {

Missing newline in /hibernate-core/src/main/java/org/hibernate/service/internal/AbstractServiceRegistryImpl.java
236: 		} finally {
Missing newline in /hibernate-core/src/main/java/org/hibernate/service/internal/AbstractServiceRegistryImpl.java
381: 					} finally {
Missing newline in /hibernate-core/src/main/java/org/hibernate/service/internal/AbstractServiceRegistryImpl.java
392: 		} finally {
Missing newline in /hibernate-core/src/main/java/org/hibernate/service/internal/AbstractServiceRegistryImpl.java
410: 		} finally {
Missing newline in /hibernate-core/src/main/java/org/hibernate/service/internal/AbstractServiceRegistryImpl.java
428: 		} finally {
Missing newline in /hibernate-core/src/main/java/org/hibernate/service/internal/AbstractServiceRegistryImpl.java
456: 		} finally {
Missing newline in /hibernate-core/src/main/java/org/hibernate/service/internal/AbstractServiceRegistryImpl.java
481: 		} finally {
Missing newline in /hibernate-core/src/main/java/org/hibernate/service/internal/AbstractServiceRegistryImpl.java
523: 		} finally {
Missing newline in /hibernate-core/src/main/java/org/hibernate/boot/registry/internal/StandardServiceRegistryImpl.java
124: 		} finally {
Missing newline in /hibernate-core/src/main/java/org/hibernate/boot/registry/internal/StandardServiceRegistryImpl.java
136: 		} finally {
Missing newline in /hibernate-core/src/main/java/org/hibernate/boot/registry/internal/StandardServiceRegistryImpl.java
148: 		} finally {
Missing newline in /hibernate-core/src/main/java/org/hibernate/boot/registry/internal/StandardServiceRegistryImpl.java
159: 		} finally {
Missing newline in /hibernate-core/src/main/java/org/hibernate/cache/spi/AbstractRegionFactory.java
99: 			} finally {
Missing newline in /hibernate-core/src/main/java/org/hibernate/cache/spi/AbstractRegionFactory.java
122: 			} finally {

[gavinking]

I'm not convinced that any of these things are problems.

These synchronized blocks are only entered at bootstrap time, when nothing is supposed to be processing concurrently.

@Sanne Are you sure these changes are actually necessary?

[Sanne]

Hi @gavinking !

I'm assuming they might be problematic even when only processed at bootstrap time, as we don't really control what kind of threads are being used to boot the ORM; I know of several patterns being used in which it's booted lazily, so potentially within another application thread (as opposed to a managed container), or even as one-offs, like using a SessionFactory only once or per-thread. Not loving nor recommending any of these, but w/o such changes it would indeed fail when using Loom.

At least until this JEP is included in all Java versions which we intend to support:
https://openjdk.org/jeps/491

[gavinking]

I know of several patterns being used in which it's booted lazily, so potentially within another application thread (as opposed to a managed container), or even as one-offs, like using a SessionFactory only once or per-thread.

Pretty sure these are anti patterns and that we should never encourage such things. A user who does this has much worse performance problems than a pinned thread!

[gavinking]

w/o such changes it would indeed fail when using Loom.

What does "fail" mean here?