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

Robert Klemme (JIRA) jira-events at lists.jboss.org
Mon Nov 26 08:57:18 EST 2007


    [ http://jira.jboss.com/jira/browse/JBAS-5002?page=comments#action_12389075 ] 
            
Robert Klemme commented on JBAS-5002:
-------------------------------------

I'm all for this.  Also, it seems start() does already contain similar behavior via isFailedXA().

> 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.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        



More information about the jboss-jira mailing list