Adapter Development Kit 6.5 | webMethods Adapter Development Kit Documentation | webMethods Adapter Development Kit Installation and User’s Documentation | Run Time Activities | Retry and Recovery Architecture | Removal/Regeneration
 
Removal/Regeneration
Transient exceptions within adapters are all related to connection errors. Therefore, the connection used in the operation will need to be cleared and regenerated before a retry occurs.
Based on the AdapterConnectionException received from the adapter, Integration Server will clean the entire pool or just the current connection. The AdapterConnectionException will indicate if the entire pool needs to be cleaned or only the current connection. By default, the exception will indicate the entire pool needs to be cleaned. For most applications this is the correct behavior.
To clean the current connection, the destroy() method is called and the object is discarded. To clean the pool, the connection pool manager will be notified and all free connections will be destroyed and discarded. Any busy connections will be destroyed and discarded when they are released. The connection node will remain enabled.
The regeneration occurs when a new connection is requested. If the connection is non-pooled an attempt is made to create the connection. If successful a connection will be created and used. If the connection is pooled and only the single connection was destroyed, another connection is reserved from the pool and used. If the pool was cleared, the pool will attempt to fill to the minimum number of connections specified for the pool. If successful a connection will be reserved and used.
If the transient error still exist at any stage of the pool regeneration or connection creation you should throw an AdapterConnectionException. This will end the current retry operation and Integration Server will start another retry execution or end the retry loop if the maximum attempts have been made.