The "dirty-checking spinning out of control" issue from "Mix of..."

[thomas24]

The issue is about all DB connections being drained from the CP, from the same call with the final error message of:

"Caused by: java.sql.SQLException: javax.resource.ResourceException: IJ000453: Unable to get managed connection for java:/ActiveDS"

Debugging the issue in Intellij shows that for this simple case of reading from a Code table (static data), causes a save and flush, which causes dirty-checking. For some reason onFlushDirty() is triggered in a loop, for as many connections as the pool contains. See image below.

I believe its the doInHibernate() operation which triggers this as, flush mode is Auto. But this issue is far beyound what I know about Hibernate, hence I wanted a quick fix with a query with READ_ONLY mode.
But, I really dont know what the root cause is, as the log output for each case is a 10 leveled exception of 1000 log lines, times the number of connections in the pool.

This code has not been changed, for 10+ years, but it seems the error has been masked by another error that is just eaten up by a try-catch and dealt with on its own. Hence undetected.

Here is a beginning stack trace image from Intellij, it also shows the loop count:

[beikov]

It looks like you have a org.hibernate.Interceptor registered that tries to work with the Session, since that is the only possible reason for nested flushing to happen, even though the Javadoc explicitly says that you may not do that:

The Session may not be invoked from a callback (nor may a callback cause a collection or proxy to be lazily initialized).

Hibernate internals have changed a bit and now you’re running into this situation, but you should have never done what you did in the first place. Maybe you can share of the interceptor and I can help you understand what is wrong and how to solve the problem.