db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Katherine Marsden <kmarsdende...@sbcglobal.net>
Subject Re: Problem with a deadlock with Derby and Glassfish V2.1.1
Date Thu, 22 Dec 2011 00:25:26 GMT
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 
>                                                 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.

View raw message