db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From dag.wan...@oracle.com (Dag H. Wanvik)
Subject Re: Deadlock problem with Derby in production
Date Tue, 15 May 2012 00:49:39 GMT

"Bergquist, Brett" <BBergquist@canoga.com> writes:

> Also suspicious is that 5 seconds before in the derby.log is:
> There was an XA transaction associated with the connection being closed. The transaction
is going to be rolled back. The transaction Xid is (4871251,f19f0201d1f69e27636776776e6a73767230312c7365727665722c5033373030,636776776e6a73767230312c7365727665722c50333730302c00).
> Exception in thread "DRDAConnThread_61" java.lang.NullPointerException
>         at org.apache.derby.impl.jdbc.EmbedConnection.cancelRunningStatement(Unknown
>         at org.apache.derby.jdbc.XATransactionState.cancel(Unknown Source)
>         at org.apache.derby.jdbc.ResourceAdapterImpl.cancelXATransaction(Unknown Source)
>         at org.apache.derby.impl.drda.DRDAXAProtocol.rollbackCurrentTransaction(Unknown
>         at org.apache.derby.impl.drda.DRDAConnThread.closeSession(Unknown Source)
>         at org.apache.derby.impl.drda.DRDAConnThread.run(Unknown Source)

you did see an NPE on the client side too, so this is a good
candidate. At least it is *one* bug: This NPE should not happen.

The connthread causing this is closing the session, and the lcc
(language connection context) or the statement context is null and leads
to the NPE, cf. code in EmbedConnection.cancelRunningStatement:

public void cancelRunningStatement() {

I don't know under what scenario this can happen; it could be a valid
one (if so, this code misses some checks), or an indication something
already went wrong. Maybe some of our XA experts could chime in :)

The client code receiving the NPE is doing a prepare statement, but the
call to closeSession seems to indicate some error already
happened. Maybe the protocol error you see in derby.log leads to the
attempt to close down the session. Just a check: does the client jar run
the at the same derby version as the server here?

Not sure the above corresponds to the hanging client thread, since that
thread seems to be doing an XA commit and waiting for an answer. The
hanging client thread is possibly a follow-on error (Glassfish
cleaning out the pool)?


View raw message