Problem Description
===============

Using AIS Tuxedo Adapter with Oracle’s BPEL under OC4J the following messages appear intermittently in the OC4J logs:

Could not invoke operation 'XYZ1' against the 'AttunityResourceAdapter' due to:
com.attunity.adapter.core.acp.AcpProtocolException : [J0036] = client.baddat ()

Could not invoke operation 'XYZ2' against the 'AttunityResourceAdapter' due to:
javax.resource.ResourceException: [J0006] Operation on already closed managed connection was requested

Could not invoke operation 'XYZ3' against the 'AttunityResourceAdapter' due to:
javax.resource.spi.CommException: Read timed out

Could not invoke operation 'XYZ4' against the 'AttunityResourceAdapter' due to:
javax.resource.spi.CommException: [J0104] {0}, reconnect can not be called under transaction

Following some of the above, the BPEL instance may need to be restarted to resume normal operation.


Technical analysis
================

These errors relate to configuration issues with the specific customer solution.

The [J0006] error directly results from setting client idle timeout on the adapter definition that is shorter than the client idle timeout set at the daemon workspace definition.

Attunity recommends that the client idle timeout is only set in the clinetIdleTimeout daemon workspace definition. The maxIdleTimeout setting in the adapter definition must always be 0 (not defined – else [J0006] exception may be repeatedly reported after idle timeout). When using client idle timeout, it _must_ be set to a time shorter by a few minutes than the client idle timeout that is set for the underlying Tuxedo services (in the UBBCONFIG file under CLOPTS=”… -- … -T xx” where xx is the timeout in minutes).

It is important that the JCA client (used by BPEL) will be the one closing the connection on idle and, therefore, it will be the one doing the reconnect later on. The backend Tuxedo connection cannot be automatically reconnected the same way the JCA connection can on idle timeout. Unfortunately, BPEL does not have a facility in its connection pool to close idle connection after some idling timeout and because of that, a connection that idled for too long may give an error the next time it is used (e.g. as a [J0104] exception).

Both the [J0036] exception as well as the read timeout relate to transaction timeout setting. In general, one should set the expected transaction timeout in the adapter definition – this setting should reflect the expected time for the Tuxedo services to complete plus some buffering (e.g., to account for some performance slowdown during load). The transaction timeout setting in OC4J must be *longer_ than the one defined at the adapter. This is important since time out in the client forces reconnection whereas a timeout in Tuxedo call just return an exception and the connection is maintained. The JCA timeout setting is defined in the following files:

J2EE_HOME/config/transaction-manager.xml
J2EE_HOME/application-deployments/orabpel/ejb_ob_engine/orion-ejb-jar.xml (all 6 settings)

In the case where these error occurred, the transaction timeout at the adapter was very long but in BPEL it was short, hence the errors. Some of the errors resulted from a service that normally took 5 seconds to complete but in this case took more than 10 minutes. Here, a proper transaction timeout setting at the adapter would have flagged this as a failure much earlier and with a more meaningful message.

Generally, when there are long running transactions, they should be placed in a separate adapter for which all timeout settings may be much higher (hours, days, etc). A single adapter should not mix short and long running services.