Avoid returning no-op delegates from CollectionAction
Description
CollectionAction.AfterTransactionCompletionProcess and CollectionUpdateAction.AfterTransactionCompletionProcess may often return delegates that do nothing. These delegates however will keep references to persistent objects in memory. For a transaction that is doing a large amount of work, this can become a problem.
The gist of the current implementation is:
return delegate { if (need to do work) { do work } }
"need to do work" in both cases evaluates to Persister.HasCache, which AFAICT cannot change, so it should be safe to evaluate when fetching the delegate:
if (need to do work) { return delegate { do work } } else { return null; }
For sessions/transactions doing bulk loading where objects can be saved, flushed, and then evicted, this change (if it is indeed safe) would, I think, reduce the memory needed quite a bit.
As it stands, when doing such a bulk loading transaction, NHibernate (via these delegates) keeps a reference to every collection that has been updated during the transaction, even if all objects have been flushed and evicted.
It looks like it might be possible to put even more outside the delegate body to reduce memory load, such as creating the CacheKey object(s), but I don't understand how those work and are used well enough to be at all sure that's safe.
CollectionAction.AfterTransactionCompletionProcess and CollectionUpdateAction.AfterTransactionCompletionProcess may often return delegates that do nothing. These delegates however will keep references to persistent objects in memory. For a transaction that is doing a large amount of work, this can become a problem.
The gist of the current implementation is:
return delegate {
if (need to do work) {
do work
}
}
"need to do work" in both cases evaluates to Persister.HasCache, which AFAICT cannot change, so it should be safe to evaluate when fetching the delegate:
if (need to do work) {
return delegate {
do work
}
} else {
return null;
}
For sessions/transactions doing bulk loading where objects can be saved, flushed, and then evicted, this change (if it is indeed safe) would, I think, reduce the memory needed quite a bit.
As it stands, when doing such a bulk loading transaction, NHibernate (via these delegates) keeps a reference to every collection that has been updated during the transaction, even if all objects have been flushed and evicted.
It looks like it might be possible to put even more outside the delegate body to reduce memory load, such as creating the CacheKey object(s), but I don't understand how those work and are used well enough to be at all sure that's safe.