Do you have a test case so that we can try to reproduce the problem ?
If yes, please raise a jira with the attached junit test.
Regards,
Guillaume
Jörg Heinicke wrote:
Von: "Jörg Heinicke" <Joerg.Heinicke_at_gmx.de>
Datum: Tue, 13 Dec 2005 18:37:04 +0100 (MET)
I'm fighting with a NPE in XAPool's StandardXAConnection when having a
connection error. I cause this connection error in my test case with a
dead lock, which is recognized correctly, but probably not handled
correctly by one of the involved components. My test involves Spring
(declarative transaction management), Jencks, Tranql, XAPool and the
Geronimo connector.
Actually the exception is thrown in
org.tranql.connector.jdbc.PreparedStatementHandle, which informs the
ConnectionHandle in the same package using connectionError(SQLException)
[1]. Now it gets interesting. At the end this connection error is
propagated to Geronimo's ConnectionEventListener, which causes the
destruction of the ManagedXAConnection instance [2] and so the closing
of the StandardXAConnection [3], which resets connectionHandle instance
variable.
So far so good. Unfortunately after the destruction of the connection,
the transactionally demarcated method is left and Spring's transaction
manager causes a rollback due to the caught exception. This brings us
back to StandardXAConnection and there the end(Xid, int) method. Inside
of it the connectionHandle instance variable is accessed [4], but
actually already null.
Now I would like to know who plays wrong in this game. Which component
behaves not correctly and should be fixed? It might be difficult to say
without more details, but I can probably provide more when needed.
Does nobody have any idea what's wrong?
To rephrase my questions:
May the ManagedConnection implementation immediately by destroyed on a
connection error with the effect of closing the physical connection (here
XAConnection implementation)? Is it correct or does it make sense at all to
cause a rollback after a connection error? Or must the XAConnection
implementation be able to handle a call to end(Xid, int) after close() has
already been called?
Regards,
Jörg
