Looking briefly at this issue I see that
does not actually flow anything, but rather sets up a cache of what to flow on the first sql statement. The trouble is that the next thing that flows may not be an sql statement but rather could be an xa call or
maybe other things. This will cause unpredictable results on the next call.
Some options might be
1) Get rid of the optimization and just flow the reset when we call getConnection.
2) Instead of keeping a separate cache, write the bytes into the agents write buffer in Reply.java, so it won't be missed regardless of the call.
Regardless, a fair amount of pull apart and put back together is required to fix this bug.
Since it is a negative case, I suggest it be deferrred to 10.2 with a comment in the release notes.