Exactly-once processing for a trigger consumes server resources and can introduce latency into message processing by triggers. For example, when Integration Server maintains a history of persistent messages processed by a JMS trigger (or guaranteed documents for a webMethods messaging trigger), each trigger service execution causes two inserts into the document history database. This requires Integration Server to obtain a connection from the JDBC pool, traverse the network to access the database, and then insert entries into the database.

Additionally, when the delivery count cannot conclusively determine the status of a message or document, Integration Server must obtain a database connection from the JDBC pool, traverse the network, and query the database to determine whether the trigger processed the message.

If querying the document history database is inconclusive or if the server does not maintain a document history for the trigger, invocation of the document resolver service will also consume resources, including a server thread and memory.

The more duplicate detection methods that are configured for a trigger, the higher the quality of service. However, each duplicate detection method can lead to a decrease in performance.

If a trigger does not need exactly-once processing (for example, the trigger service simply requests or retrieves data), consider leaving exactly-once processing disabled for the trigger. However, if you want to ensure exactly-once processing, you must use a document history database or implement a custom solution using the document resolver service.