Extenuating Circumstances for Exactly-Once Processing
Although Integration Server provides robust duplicate detection capabilities, activity outside of the scope or control of the subscribing Integration Server might cause a trigger to process a document more than once. Alternatively, situations can occur where Integration Server might determine a document is a duplicate when it is actually a new document.
For example, in the following situations a trigger with exactly‑once processing configured might process a duplicate document.
If the client publishes a document twice and assigns a different UUID each time,
Integration Server does not detect the second document as a duplicate. Because the documents have different UUIDs,
Integration Server processes both documents.
If the document resolver service incorrectly determines the status of a document to be new (when it is, in fact, a duplicate), the server processes the document a second time.
If a client publishes a document twice and the second publish occurs after the server removes the expired document UUID entries from the document history table,
Integration Server determines the second document is new and processes it. Because the second document arrives after the first document’s entries have been removed from the document history database,
Integration Server does not detect the second document as a duplicate.
If the time drift between the computers hosting a cluster of
Integration Servers is greater than the duplicate detection window for the trigger, one of the
Integration Servers in the cluster might process a duplicate document. (The size of the duplicate detection window is determined by the
History time to live property under
Exactly Once.) For example, suppose the duplicate detection window is 15 minutes and that the clock on the computer hosting one
Integration Server in the cluster is 20 minutes ahead of the clocks on the computers hosting the other
Integration Servers. A trigger on one of the slower
Integration Servers processes a document at 10:00 GMT. The
Integration Server adds two entries to the document history database. Both entries use the same time stamp and both entries expire at 10:15 GMT. However, the fast
Integration Server is 20 minutes ahead of the others and might reap the entries from the document history database before one of the other
Integration Servers in the cluster does. If the fast
Integration Server removes the entries before 15 minutes have elapsed and a duplicate of the document arrives, the
Integration Servers in the cluster will treat the document as a new document.
Note:
Time drift occurs when the computers that host the clustered servers gradually develop different date/time values. Even if the Integration Server Administrator synchronizes the computer date/time when configuring the cluster, the time maintained by each computer can gradually differ as time passes. To alleviate time drift, synchronize the cluster node times regularly.
In some circumstances Integration Server might not process a new, unique document because duplicate detection determines the document is duplicate. For example:
If the publishing client assigns two different documents the same UUID,
Integration Server detects the second document as a duplicate and does not process it.
If the document resolver service incorrectly determines the status of a document to be duplicate (when it is, in fact, new), the server discards the document without processing it.
Important:
In the above examples, Integration Server functions correctly when determining the document status. However, factors outside of the control of Integration Server create situations in which duplicate documents are processed or new documents are marked as duplicates. The designers and developers of the integration solution need to make sure that clients properly publish documents, exactly-once properties are optimally configured, and that document resolver services correctly determine a document’s status.