On 12/21/2011 3:14 PM, Bergquist, Brett wrote:
Will get to this tomorrow but I do see one comment in the code that I
don't understand:
In DRDAConnThread.java, I see:
if (severity > CodePoint.SVRCOD_ERROR)
{
// For a session
ending error > CodePoint.SRVCOD_ERROR you cannot
// send a SQLERRRM. A
CMDCHKRM is required. In XA if there is a
// lock timeout it
ends the whole session. I am not sure this
// is the correct
behaviour but if it occurs we have to send
// a CMDCHKRM instead
of SQLERRM
writeCMDCHKRM(severity);
}
So what does the comment "In XA if there is a lock timeout it ends the
whole session" refer to. Why would a lock timeout be any different
than any other standard database error. It is like this is hinting at
what is happening.
This is a real XA transaction.
What I see is that after the timeout is hit (I see it hit in
Timeout.java) the error is propagated to the app server. The app
server then attempts to get the error text (I don't have the code
handy) which attempts to send a request back to the Derby. This then
fails with a No Connection error being returned back from Derby. It
is as if after this error, the connection between the app server and
Derby is no longer once there this is hit.
I agree that would not be the correct behavior if a lock timeout killed
the session. As this is a server side comment it would imply that this
is a problem with embedded as well as well, but hard to believe it would
not have been exposed before now. Thanks for working on reproduction for
this. I don't see the comment in the original code import but the
annotation is not clear as it mentions the back out of another fix, so I
am not sure who first noticed this behavior.
