Exactly-once processing for a trigger consumes server resources and can introduce latency into document processing by triggers. For example, when Integration Server maintains a history of guaranteed documents processed by a 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 redelivery count cannot conclusively determine a document’s status, the server must obtain a database connection from the JDBC pool, traverse the network, and query the database to determine whether the trigger processed the document.

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.