Running Business Processes and Composite Applications 10.4 | Running Business Processes and Composite Applications | webMethods Integration Server Administrator’s Guide | Configuring Guaranteed Delivery | Configuring the Server for Guaranteed Delivery | Settings for Inbound Transactions
 
Settings for Inbound Transactions
For inbound transactions, the server maintains a job store of transactions and the status of each. Periodically, the server sweeps the job store to remove expired transactions; that is, to remove transactions that have an elapsed time-to-live (TTL) period. For inbound requests, the client must specify the TTL for a transaction.
In addition to the job store, the server maintains an audit-trail log of all operations it performs for inbound transactions.
The following table identifies the inbound transaction settings that you can configure.
You can configure:
Using this setting
How often the server sweeps the job store to remove expired transactions
watt.server.tx.sweepTime
How the server updates the status of PENDING transactions when a heuristic failure occurs
watt.server.tx.heuristicFailRetry
watt.server.tx.sweepTime
Use the watt.server.tx.sweepTime setting to specify the number of seconds between sweeps (clean up) of the job store of inbound transactions. The server sweeps the job store to remove expired transactions.
The default is: 60 seconds
watt.server.tx.heuristicFailRetry
Use the watt.server.tx.heuristicFailRetry setting to indicate whether the server is to re-execute services for transactions in the job store that are PENDING when the server is restarted after a failure. If a transaction is PENDING, the service began but did not complete execution when the server failed.
Because the server cannot determine the exact status of a service request, the server considers the guaranteed transaction to have encountered a heuristic failure. You can configure the server to respond to heuristic failures as appropriate. The default watt.tx.heuristicFailRetry setting causes the server to execute a service at least one time at the risk of re-executing it a subsequent time after a heuristic failure. Alternatively, you can reconfigure the setting to guarantee that a service is executed at most one time at the risk of not executing a service due to a heuristic failure.
If the watt.tx.heuristicFailRetry setting is true, the server resets the transaction status from PENDING to NEW, and the server will retry the service. When the setting is true, a request to execute a service can only fail if the transaction expires before the server executes the service. (The client specifies the settings that indicate when a transaction expires.)
If the watt.tx.heuristicFailRetry setting is false, the server resets the transaction status from PENDING to FAIL to indicate the heuristic failure; the server does not retry the service. When the setting is false, a request to execute a service can fail due to a heuristic failure or due to the transaction expiring.
The default is: true

Copyright © 2019 | Software AG, Darmstadt, Germany and/or Software AG USA, Inc., Reston, VA, USA, and/or its subsidiaries and/or its affiliates and/or their licensors.
Innovation Release