In 2 weeks I will be releasing 5.3 CR2. I waned to start a unified
discussion about the remaining currently unresolved discussions and what
exactly we are going to do for 5.3 mainly in regards to compatibility with
an eye to 6.0
Cache region-name as exposed in API/SPI
This one is a "sneaky" compatibility concern. When discussing this, it
seems like we had a consensus that the way this should work is for the name
passed in to be un-prefixed. Unfortunately the current behavior is to
accept the qualified region name. IMO we should change this. However,
there is a big danger in that : it would introduce a run-time behavior
incompatibility, as opposed to a compile one, which in a way is worse. See
the new test I just added to master for examples of what I mean
One option for compatibility is to introduce a new compatibility flag for
this. Something like "hibernate.cache.region_name_api_prefixed"
(true/false). Or a better way might be to accept either, and to avoid the
extra perf hit of add a new setting to disallow calls with the prefixed
Also Sanne brought up the idea of ORM simply no longer dealing with prefix
(this is at odds with the current API/SPI calls as tested).
It was decided to include HHH-11356 (cache SPI redesign) in 5.3. See
the Jira for details.
HHH-11356 redefines how regions and access strategies are structured,
related and accessed. I won't get too in to the details here (read the
Jira if interested) but that required changes to other code that uses the
SPI. Most of those are internal and were easy to adjust. However
Statistics, as a consumer of these regions and access strategies, also
required some changes. HHH-12323 is the Jira for these changes.
Again the see the Jira for details.
The other major change for 6.0 is the metamodel, type system change. This
one is pervasive. All of the strategies to bridge Type and read-by-name /
read-by-position, imo, are not feasible.
The changes in the run-time metamodel are too much to bridge, which is a
complicating factor. Right down to PersisterFactory.
P.S. where there is already a Jira it would be best if we can keep the
discussions on the Jira itself.
Issue HHH-12353 was just reported and I have to agree it looks dodgy.
entityManager.getReference( Person.class )
might not return a type compatible with Person, when Person is final
and annotated with @Proxy(proxyClass = AnotherTypeX.class), then
AnotherTypeX might be returned and this is not necessarily a subtype
That's ok as I understand we hardly have alternatives, but the
EntityManager API for getReference mandates this signature:
<T> T getReference(Class<T> entityClass, Object primaryKey)
so we're not actually returning the expected type T in all
circumstances, confusing compilers and tooling into giving the wrong
I see some options:
a# disallow using @Proxy on a final entity - seems reasonable since
the docs warn against pitfalls.
b# throw an exception on Person.class being used as parameter, as the
user should actually use the proxytype?
c# somehow have the proxy still extend the final entity?
Option b# seems problematic as it's not obvious to users either, and
we would need to return a proxy reference even when there actually is
a managed Person instance in the current session.
Option c# is probably unrealistic and problematic too, as it would
require enhancing of the final class and I guess we can't rely on that
In summary, I believe we should throw a bootstrap exception requiring
to remove the `final` modifier on the parent entity. Or challenge the
On Mon, Mar 5, 2018 at 2:15 PM, Christian Beikov <christian.beikov(a)gmail.com
> I have a fix for the NPE the user reported, but there is one edge case,
> which hasn't been rerported yet as it seems exotic, that I am still trying
> to figure out.
> I can provide the "partial fix" later today if you like, but I'd prefer to
> fix the overall problem before releasing.
I'd say let's try to have a proper global fix, but if it's too long to get
the right fix, let's revisit this decision.
Just MHO, let's wait for Steve and the others.
So, I started the effort of making our version properties consistent with
JBoss parent/WildFly parent with Search but the idea is to generalize this
to all our NoORM projects and be as consistent as possible between the
The idea is to, as much as possible, use the exact same notation as the
other JBoss projects when declaring the version properties of our
You can see what it implies in this diff:
So, from now on, when you need to add new dependencies in Search:
- check if JBoss parent or WildFly parent already contains this dependency,
if so use the exact same property name
- if not, use <version.full.package.name> if it is descriptive and
- if the package name is used for several artifacts or is not descriptive
enough, use <version.full.package.name.artifact-id>
My plan is to be done with OGM in 2 weeks and do it for HV 6.1 as I don't
want to do it in a micro.
So please avoid big pom refactorings in OGM for the next 2 weeks.
Dependency upgrades are OK, I'll merge them along the way.
I have this exception with latest 5.2.14 (my project runs fine with 5.2.13):
Caused by: javax.persistence.PersistenceException: [PersistenceUnit:
default] Unable to build Hibernate SessionFactory
... 32 more
Caused by: org.hibernate.MappingException: Could not instantiate persister
... 39 more
Caused by: java.lang.NullPointerException
... 44 more
Public PGP Key at:
Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611
Currently, when a lazy group is loaded that has associations, there are 2
SQL statements executed.
For example, suppose the DEFAULT lazy group contains the following:
* Order#customer is a lazy many-to-one association;
* Order#text is a lazy LOB.
When one of these properties is referenced, Hibernate loads both of them.
Currently, it takes 2 SQL statements to get the association loaded.
1) Loads #text and the FK value for #customer (select o.text, o.customer_id
from orders o where o.id = ?)
2) Loads the state for #customer (select ... from customers c where c.id =
In other words, FetchMode.SELECT is used to load associations in a lazy
HHH-11223 involves combining the 2 SQL statements into a single statement
using a join (i.e., using FetchMode.JOIN), but only when at least one of
the following is true:
* caching is disabled for the SessionFactory (e.g., hibernate.cache.use_sec
* caching is not enabled for "get" operations (i.e.,
session.getCacheMode().isGetEnabled() == false);
* the associated entity type (and subclasses?) is not cached
HHH-11223 only mentions to-one associations, but I think collections in a
lazy group could also be loaded using a join as well.
I think I'm pretty close, but I need to do a lot more testing to ensure it
covers things like:
* lazy association in composite ID
* lazy association in an embeddable
* lazy association in a secondary table
* lazy association in a subclass
* too many bags
This is what I have implemented so far:
At the moment, I'm not looking for a comprehensive review. I'm just looking
for a review of the overall design.
I don't want to get into the nitty-gritty here, but, basically, I've
created a new type of AbstractLoadPlanBasedEntityLoader, LazyGroupLoader,
which loads the lazy group properties into the existing entity.
If caching is disabled for the SessionFactory, then one loader is
constructed per lazy group, and associations will be loaded using
If caching is enabled for the SessionFactory, then 2 loaders are
constructed per lazy group. One loader is used when caching is enabled for
"get" operations (using Fetch.SELECT for cached associated
entities/collections; Fetch.JOIN for other associations). The other loader
is used when caching is disabled for "get" operations.
Here are some of the changes to the default behavior (described above) that
could be useful:
1) Change all associations in lazy groups to be loaded using
FetchMode.SELECT (as is currently done without the fix), or using
FetchMode.JOIN (regardless of caching). A new configuration property could
hibernate.bytecode.lazyGroup_association_fetchMode=(default | select | join
2) Allow the FetchMode to be configured for a particular lazy association.
According to the documentation , @Fetch can't be used for this because,
"... FetchMode.JOIN acts as a FetchType.EAGER strategy. Even if we mark the
association as FetchType.LAZY, the FetchMode.JOIN will load the association
A new annotation could be introduced: @LazyFetch.
Comments or suggestions?
HHH-10478 is currently scheduled for 6.0.0.alpha1. What do you think about
introducing it into 5.3.0 instead?
Using an OperationContext would be a less hacky way to fix HHH-3799
(PersistentSet does not honor hashcode/equals contract when loaded eagerly).
It would be nice to remove operation-specific fields from
private int cascading;
private int loadCounter;
private int removeOrphanBeforeUpdatesCounter;
private boolean flushing;
private boolean defaultReadOnly;
private boolean hasNonReadOnlyEntities;
private LoadContexts loadContexts;
Without using an Operation context, the fix for HHH-3799would add something
private boolean isEntityLoading;
HHH-11253 is about making ByteBuddy the default implementation, but
it's flagged for 6.
I think that in Paris there was consensus to make it the default in
5.3 alredy, to possibly drop Javassist entirely in 6.0.
May I change this to 6 ? If that's ok, I can assign it to myself.