I deployed on our servers a 4.1.8 version patched with HHH-7829 fixed (as it was in the way) and some additional logging in BatchFetchQueue.
After more time looking at the code, I'm wondering if the collection batch fetching patch has missed something in AbstractFlushingEventListener.postFlush().
Shouldn't we also clean up the batchLoadableCollections map from persistenceContext.getBatchFetchQueue() in AbstractFlushingEventListener.postFlush()?
Currently, only the subselectsByEntityKey map is cleaned up:
AbstractFlushingEventListener.java
persistenceContext.getBatchFetchQueue()
.clearSubselects(); //the database has changed now, so the subselect results need to be invalidated
and I think that considering all the collection cleanup that comes afterwards in the very same method, persistenceContext.getBatchFetchQueue().batchLoadableCollections should also be cleaned up.
The fact is that what triggered this NPE for us is a batch loading script where we do session.flush() / session.clear() every N objects.
By the way, I took a look at how CollectionEntry.loadedKey was used in the code and it seems that it might be null sometimes (see the start of CollectionEntry.preFlush):
this condition was added by Steve in the following commit: https://github.com/hibernate/hibernate-orm/commit/183c914f5769f7072fd9ff8d5591e816dfc0c353 . I'm not convinced it's related to our problem though as we don't use JoinColumn in our application but I think it was worth mentioning that I'm not sure we can consider the loadedKey being non null. There are a couple of other tests on ce.getLoadedKey() != null in the code.
Note that it might be OK in the specific cases we send to the collection batch fetching code but it might be worth it to double check.
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
I deployed on our servers a 4.1.8 version patched with
HHH-7829fixed (as it was in the way) and some additional logging in BatchFetchQueue.After more time looking at the code, I'm wondering if the collection batch fetching patch has missed something in AbstractFlushingEventListener.postFlush().
Shouldn't we also clean up the batchLoadableCollections map from persistenceContext.getBatchFetchQueue() in AbstractFlushingEventListener.postFlush()?
Currently, only the subselectsByEntityKey map is cleaned up:
persistenceContext.getBatchFetchQueue() .clearSubselects(); //the database has changed now, so the subselect results need to be invalidated
and I think that considering all the collection cleanup that comes afterwards in the very same method, persistenceContext.getBatchFetchQueue().batchLoadableCollections should also be cleaned up.
The fact is that what triggered this NPE for us is a batch loading script where we do session.flush() / session.clear() every N objects.
By the way, I took a look at how CollectionEntry.loadedKey was used in the code and it seems that it might be null sometimes (see the start of CollectionEntry.preFlush):
this condition was added by Steve in the following commit: https://github.com/hibernate/hibernate-orm/commit/183c914f5769f7072fd9ff8d5591e816dfc0c353 . I'm not convinced it's related to our problem though as we don't use JoinColumn in our application but I think it was worth mentioning that I'm not sure we can consider the loadedKey being non null. There are a couple of other tests on ce.getLoadedKey() != null in the code.
Note that it might be OK in the specific cases we send to the collection batch fetching code but it might be worth it to double check.