The Cascade class makes unnecessary calls to the Reflection API.


There are two places in Cascade class where unnecessary calls to the Reflection API are made:

1. In the method Cascade#cascade(CascadingAction, CascadePoint, EventSource, EntityPersister, Object, Object):
When the CascadingAction PERSIST_ON_FLUSH is used, then for some CascadeStyles of a property the method CascadingAction#noCascade may be called. This method requires now the current value of a property. But the property value is only used when the property type is an EntityType. Therefore we can reduce the number of calls to the Reflection API if we change the signature of the method CascadingAction#noCascade to take the property type instead of the property value and the property value can be looked up in the CascadingAction#noCascade if it is really needed.

2. In the method Cascade#cascadeComponent(CascadingAction, CascadePoint, EventSource, int, Object, Object, CompositeType, Object):
Here is a similar problem: not all CascadeStyles of a component property require cascading. There are situations where all CascadeStyles of all component properties do not require cascading. Therefore we can delay getting the property values of a component until they are needed and reduce so the number of calls to the Reflection API.




Steve Ebersole
December 16, 2015, 9:04 PM

Applied Andrej's PR upstream

Frank Prumbaum
January 25, 2016, 7:48 AM

After upgrading from 5.0.5.Final we see many errors like this

at org.hibernate.collection.internal.AbstractPersistentCollection$5.hasNext(
at org.hibernate.engine.internal.Cascade.cascadeCollectionElements(
at org.hibernate.engine.internal.Cascade.cascadeCollection(
at org.hibernate.engine.internal.Cascade.cascadeAssociation(
at org.hibernate.engine.internal.Cascade.cascadeProperty(
at org.hibernate.engine.internal.Cascade.cascade(

This may be due to some incorrect data mapping on our side but there should not be any NPE?

Sorry for capturing this issue, but after seeing through the changes for 5.0.6 and 5.0.7 this issue seemed to be the propable cause.

Steve Ebersole
January 25, 2016, 3:33 PM

Going to need a test case that reproduces this. If you can create a testcase that reproduces it, please open a new bug report and attach the testcase there. Thanks.

Frank Prumbaum
January 27, 2016, 9:11 AM

While trying to do just that we found the cause to be an @Async-Spring-Annotation while not providing the necessary transactional context for doing a entityManager.merge(entity).
Please excuse the noise.


Steve Ebersole


Andrej Golovnin

Fix versions





Suitable for new contributors

Yes, likely

Requires Release Note