[jboss-jira] [JBoss JIRA] Commented: (JBAS-5002) Include XAER_RMERR and XAER_RMFAIL connectionErrorOccurred processing in the XAResourceWrapper

Include XAER_RMERR and XAER_RMFAIL connectionErrorOccurred processing in the XAResourceWrapper ---------------------------------------------------------------------------------------------- Key: JBAS-5002 URL: http://jira.jboss.com/jira/browse/JBAS-5002 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public(Everyone can see) Components: JCA service Affects Versions: JBossAS-4.2.2.GA Reporter: Adrian Brock Since we have an XAResourceWrapper for all XAResources within the JCA connection manager now, we should use it to track all events on the XAResource protocol. If any event throws an XAER_RMERR or XAER_RMFAIL then we should fire a connectionErrorOccurred event on the associated connection manager's ConnectionListener to close the connection (assuming it is not already destroyed - i.e. the resource adapter did it itself). This is just a "fixup" feature for resource adapters that don't do this themselves. e.g. something like public class XAResourceWrapper() { ... public void prepare(Xid xid) throws XAException { try { delegate.prepared(Xid xid); } catch (XAException e) { checkFailure(); throw e; } catch (RuntimeException e) { checkFailure(); throw new XAException(..., e); // XAER_RMERR } catch (Error e) { checkFailure(); throw new XAException(..., e); // XAER_RMERR } } protected void checkFailure(XAException e) { if (connectionManager.getFireResourceError() && (e.errorCode = XAException.XAER_RMERR || e.errorCode= XAER_RMFAIL)) { connectionListener.connectionErrorOccurred(new ResourceException("Error in resource manager" + connectionLisetener, e)); } } } For backwards compability there should be a flag to turn off the behaviour in case it causes problems. e.g. <xa-datasource> ... <!-- Try to think of a better name? --> <fire-resource-failure-event>false</fire-resource-failure-event> </xa-datasource> But it should be true by default since it is unlikely that any connection that reported those XAExceptions should be returned to the pool.