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.
|