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

[Adrian Brock (JIRA)]

     [ http://jira.jboss.com/jira/browse/JBAS-5002?page=all ]

Adrian Brock updated JBAS-5002:
-------------------------------

        Summary: Include XAER_RMERR and XAER_RMFAIL connectionErrorOccurred processing in the XAResourceWrapper  (was: Include XA_RMERR and XA_RMFAIL connectionErrorOccurred processing in the XAResourceWrapper)
    Description: 
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.

  was:
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 XA_RMERR or XA_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); // XA_RMERR
       }
       catch (Error e)
       {
            checkFailure();
            throw new XAException(..., e); // XA_RMERR
       }
   }
   protected void checkFailure(XAException e)
   {
         if (connectionManager.getFireResourceError() && (e.errorCode = XAException.XA_RMERR || e.errorCode= XA_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.


> 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