Have you tried swapping out one of the components, such as the database connection pool you are using? I moved away from XAPool to c3p0 several months ago due to NPE's in load tests in XAPool.
http://www.mchange.com/projects/c3p0/index.html Good luck. If you need help setting up c3p0 in Spring XML, let me know. Cameron On 12/22/05, "Jörg Heinicke" <[EMAIL PROTECTED]> 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 > > -- > Telefonieren Sie schon oder sparen Sie noch? > NEU: GMX Phone_Flat http://www.gmx.net/de/go/telefonie >
