Hi,
it seems, that the implementation of org.hibernate.engine.internal.Cascade has a poor influence to performance in big transactions.
In flush prepare operations, Hibernate checks each property on every entity that is part of the transaction cache:
- First: Hibernate reads the property value via reflection
- Second: Hibernate checks if the property is already an entity type or not
If the second step finds out, that it is not an entity type, the reflection of the first step was needless
When sampling the transaction flush, we found out, that the useless reflection has a poor influence to performance in big transactions. Even Hibernate 5 has this code:
Code:
public final class Cascade {
...
public void cascade(final EntityPersister persister, final Object parent, final Object anything) {
...
else if ( action.requiresNoCascadeChecking() ) {
action.noCascade(
eventSource,
persister.getPropertyValue( parent, i ), // Here we have the 'expensive' reflection
parent,
persister,
i
);
....
Code:
public static final CascadingAction PERSIST_ON_FLUSH = new BaseCascadingAction() {
...
public void noCascade(
EventSource session,
Object child,
Object parent,
EntityPersister persister,
int propertyIndex) {
if ( child == null ) {
return;
}
Type type = persister.getPropertyTypes()[propertyIndex];
if ( type.isEntityType() ) { // And here we decide not to check the child
...
}
}
....
Our sampling has shown, that the hole org.hibernate.event.internal.DefaultAutoFlushEventListener.onAutoFlush(AutoFlushEvent) method lasts
150.207ms. About 30% of the time he made useless reflection: org.hibernate.tuple.entity.AbstractEntityTuplizer.getPropertyValue(Object, int) lasts
52.902ms. IMHO a quick solution would be:
- First: Check the property type and only if it is an entity make second step
- Second: Get property value
Do you think, this analysis is correct.
Best regards
Guido
Login
FAQ
Search