Transaction timeline / delay for Web API requests
- Last UpdatedSep 03, 2025
- 3 minute read
During the configuration of the curator service, the MES database is set to Read Committed Snapshot. This ensures that the MES Curator service will only read committed records from the database. However, there might be transactions in process that have not yet been committed; therefore, the MES Curator applies an additional delay when retrieving records from the staging tables. The TransactionTimeout setting in the appsettings.json file defines this delay. It has a default value of 1 minute. The MES Curator service adds an additional 1 minute to the setting for a total default delay of 2 minutes. A transaction running for 5 minutes to curate data is not visible for other transactions to read those curated data, until the curation entry is committed in the database.
Note: The timeline and transactions described below are just an example for the reader to understand the flow of curation, and not necessarily the typical duration of MES database transactions. This example assumes that the MES curation TransactionTimeout setting is configured for 5 minutes.
Continuing from the previous section on the production transaction example, the production record is curated at 6:07.
-
6:07:00 – The transaction starts (TransactionID:200) on staging tables.
-
6:07:30 – The curated production record is inserted. The created at datetime is 6:07:30.
-
6:11:30 – The transaction commits.
Note: 6:11:30 is when the curated records from TransactionID:200 will be visible to other transactions, even though they were updated before this time. That is, all changed data can be queried only after 6:11:30.
AVEVA Events to CONNECT agent scanning for production datatype
The following table describes the scanning behavior of the adaptor for production datatype using a 6 minute transaction buffer in the database.
The start time for the adaptor is always the Current Time minus Polling Frequency (or the last scan time) and the end time is the Current Time. This is the adaptor’s scan time range, which cannot be modified by MES.
Note: MES scales back the supplied time range from adaptor by the TransactionTimeout setting (rounding to the next minute) plus 1 minute, but the example below uses a 6 minute scale back for an easy understanding of the mechanism.
|
Scanning Behavior |
Result |
|---|---|
|
Adaptor Scan Time: 6:08:00 Adaptor Scan Time Range: 6:03:00 to 6:07:59 MES Modified Scan Time Range: 5:57:00 to 6:01:59 Note: The agent does not always scan on the top of the minute, but could scan on a second specific basis as well. To avoid any boundary issues, the MES Curator adds an additional 1 minute delay. |
Since there were no curated records in this adaptor scan cycle, no records will be returned to the adaptor. |
|
Adaptor Scan Time: 6:13:00 Adaptor Scan Range: 6:08:00 to 6:12:59 MES Modified Scan Time Range: 6:02:00 to 6:06:59 |
Since there are no curated records in this adaptor scan cycle; no records will be returned to the adaptor. |
|
Adaptor Scan Time: 6:18:00 Adaptor Scan Range: 6:13:00 to 6:17:59 MES Modified Scan Time Range: 6:07:00 to 6:11:59 |
Since the TransactionID:200 was committed by 6:07:30, the curated record falls within the scan time range, and the curated record is returned to the agent in this scan cycle. |
|
The net result with this approach is that it is guaranteed to pick up the committed records in the database, when the scan time range falls back in the past to accommodate the running transactions. |
In the example above, a curated record inserted at 06:07:30 in the staging tables is picked up by the adaptor at 6:18, with a delay of 10:30 (10 minutes and 30 seconds) from the time of curation and the time the adaptor picked up the curated record.
In the case where the staging record was curated at 6:02:00 precisely in the database, then the adaptor would have picked up that record at 6:13, with a delay of 11 minutes from the time of curation and by the time the adaptor picks up that change.
From the example above:
-
6:00:30 – Updated item_prod record in the production database.
-
6:07:30 – The updated production record is curated in the database, delayed by approximately 7 minutes from production to staging.
-
6:18:00 – The adaptor receives the update from the database, delayed by approximately 10 minutes to return data from staged to adaptor.
The net delay is approximately 17 minutes from the time the data is updated in the production database, staged, and returned to the adaptor.