|
Description:
|
From my post on the mailing list:
Hi,
After upgrading from *4.1.6* to *4.1.8*, we have a couple of regressions
in one of our applications.
We tried to obtain self contained test cases and understand what the
problem is but it's quite hard to reproduce and we haven't found a way
to isolate the problem yet.
Anyway, I was wondering if the stacktraces could ring a bell for
someone to help us analyze the problem. It might even be an obvious
bug for you once you have the stracktrace.
Here are both stacktraces for the regressions we have:
Stacktrace 1 (only when we configure the batch loading - might be due
to a race condition because it's not systematic):
{code}
Caused by: java.lang.NullPointerException
at
org.hibernate.type.descriptor.java.AbstractTypeDescriptor.extractHashCode(AbstractTypeDescriptor.java:88)
at
org.hibernate.type.AbstractStandardBasicType.getHashCode(AbstractStandardBasicType.java:210)
at
org.hibernate.type.AbstractStandardBasicType.getHashCode(AbstractStandardBasicType.java:214)
at org.hibernate.cache.spi.CacheKey.calculateHashCode(CacheKey.java:71)
at org.hibernate.cache.spi.CacheKey.<init>(CacheKey.java:67)
at
org.hibernate.internal.AbstractSessionImpl.generateCacheKey(AbstractSessionImpl.java:252)
at
org.hibernate.engine.spi.BatchFetchQueue.isCached(BatchFetchQueue.java:330)
at
org.hibernate.engine.spi.BatchFetchQueue.getCollectionBatch(BatchFetchQueue.java:312)
at
org.hibernate.loader.collection.BatchingCollectionInitializer.initialize(BatchingCollectionInitializer.java:72)
at
org.hibernate.persister.collection.AbstractCollectionPersister.initialize(AbstractCollectionPersister.java:678)
at
org.hibernate.event.internal.DefaultInitializeCollectionEventListener.onInitializeCollection(DefaultInitializeCollectionEventListener.java:80)
at
org.hibernate.internal.SessionImpl.initializeCollection(SessionImpl.java:1804)
at
org.hibernate.collection.internal.AbstractPersistentCollection$4.doWork(AbstractPersistentCollection.java:549)
at
org.hibernate.collection.internal.AbstractPersistentCollection.withTemporarySessionIfNeeded(AbstractPersistentCollection.java:234)
at
org.hibernate.collection.internal.AbstractPersistentCollection.initialize(AbstractPersistentCollection.java:545)
at
org.hibernate.collection.internal.PersistentBag.removeAll(PersistentBag.java:345)
{code}
Stacktrace 2 (we have this one even if we disable the batch loading):
Caused by: java.lang.NullPointerException
at org.hibernate.engine.internal.Cascade.cascadeProperty(Cascade.java:259)
at org.hibernate.engine.internal.Cascade.cascade(Cascade.java:165)
at
org.hibernate.event.internal.AbstractFlushingEventListener.cascadeOnFlush(AbstractFlushingEventListener.java:160)
at
org.hibernate.event.internal.AbstractFlushingEventListener.prepareEntityFlushes(AbstractFlushingEventListener.java:151)
at
org.hibernate.event.internal.AbstractFlushingEventListener.flushEverythingToExecutions(AbstractFlushingEventListener.java:88)
at
org.hibernate.event.internal.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:51)
at org.hibernate.internal.SessionImpl.flush(SessionImpl.java:1213)
at
org.hibernate.ejb.AbstractEntityManagerImpl.flush(AbstractEntityManagerImpl.java:986)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.springframework.orm.jpa.SharedEntityManagerCreator$SharedEntityManagerInvocationHandler.invoke(SharedEntityManagerCreator.java:240)
at $Proxy115.flush(Unknown Source)
Followup of this post:
The errors are quite hard to reproduce and we only have them in a *big* application with a lot of entities when we are bulk loading a lot of objects. We don't reproduce these problems on the smaller ones. That's why a self contained test case is hard to get.
They are totally reproducable on this application though.
From what we saw in the code, at least one of the stacktraces comes from a place modified in 4.1.8. That's why we hoped it could ring a bell just to have the stacktraces.
Typically this one:
Caused by: java.lang.NullPointerException
at org.hibernate.engine.internal.Cascade.cascadeProperty(Cascade.java:259)
at org.hibernate.engine.internal.Cascade.cascade(Cascade.java:165)
at org.hibernate.event.internal.AbstractFlushingEventListener.cascadeOnFlush(AbstractFlushingEventListener.java:160)
at org.hibernate.event.internal.AbstractFlushingEventListener.prepareEntityFlushes(AbstractFlushingEventListener.java:151)
at org.hibernate.event.internal.AbstractFlushingEventListener.flushEverythingToExecutions(AbstractFlushingEventListener.java:88)
at org.hibernate.event.internal.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:51)
at org.hibernate.internal.SessionImpl.flush(SessionImpl.java:1213)
at org.hibernate.ejb.AbstractEntityManagerImpl.flush(AbstractEntityManagerImpl.java:986)
seems to be related to this particular commit:
https://github.com/hibernate/hibernate-orm/commit/deaff9705e564b33b92b3eac9fdee89815ce1a44
Should we try to reproduce it in a debug environment with a conditional breakpoint to see if we can have more information about the context?
For the other one, I don't have any idea yet.
In this commit, I find a little weird that the hashCode is tested before testing the type but I don't think it might be related to the problem at hand.
https://github.com/hibernate/hibernate-orm/commit/fae0d3f49877a5a11a7ac5cef25bb91235906fab
|
