-
Bug
-
Resolution: Done
-
Minor
-
2.3
-
None
-
None
-
False
-
None
-
False
-
-
First, read AG-227
Whilst providing a big improvement, the connection management changes still appear to contain a subtle flaw that will leak connections under certain circumstances.
if ( flag == TMENDRSCAN && ( value == null || value.length == 0 ) )
{ close(); }This is designed around two assumptions: that it's invalid to close a connection during a recovery scan, since that invalidates the cursor it's using in the db, and that the connection won't be used again if the results of the scan contained no elements. Those are fine, but...
It also assumes that if the result set is non-empty, the connection will be used again. Unfortunately that's untrue in two respects. First, it doesn't actually fix the MS SQL issue that
Second and more important, there are cases where the result set is non-empty and yet the connection will not be used again. These still leak. The candidate fix is
if ( flag == TMENDRSCAN ) { close(); }
which is a bit eager on the closing, but that's better than not eager enough, since the cost of reconnecting is not high.
- impacts account
-
AG-227 Set a marker if the result set is non-empty foreach recover call
- Closed
- is depended on by
-
QUARKUS-4185 Transaction periodic recovery connection leak
- Closed