Sorry, misread the pagination article. It’s using getResultList instead of Stream, therefore fully loading the List of objects at time of query. While this is an option, it also requires a sort on the query. Instead of relying on database cursor, we now have to include/maintain pagination properties to fully iterate a set of results. This seems like added overhead that should not be required. I agree, Pagination is the best approach when dealing with UI/queries that will be limited to a smaller set of Results. However if i want to iterate over a full table, pagination doesn’t seem to be the best tool for the job.
I’m not sure I agree with the current implementation being correct. Why blatantly ignore a connection property? I understand this isn’t the most common paradigm, but it is valid nonetheless. Furthermore, this is functionality that has worked in previous versions up until 5.X. Seems silly to break functionality, and force users to upgrade to work around an issue that could easily be fixe
As for the Connection leak, this shouldn’t be a problem as long as all ResultSets and PreparedStatements are properly cleaned up upon connection close. Hibernate has gone as far as to provide the ability to postpone releasing the connection until the session is closed. If this is enabled, why not honor the ResultSet.holdability? If configured to HOLD_CURSORS_OVER_COMMIT, why forcibly close them after each commit?