Transaction timeline / delay for Web API requests
- Last UpdatedAug 29, 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 database. 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 agent for production datatype using a 6 minute transaction buffer in the database.
The start time for the agent is always the Current Time minus Polling Frequency (or the last scan time) and the end time is the Current Time. This is the agent’s scan time range, which cannot be modified by MES.
Note: MES scales back the supplied time range from agent 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 |
|---|---|
|
Agent Scan Time: 6:08:00 Agent 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 agent scan cycle, no records will be returned to the agent. |
|
Agent Scan Time: 6:13:00 Agent 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 agent scan cycle; no records will be returned to the agent. |
|
Agent Scan Time: 6:18:00 Agent 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 agent at 6:18, with a delay of 10:30 (10 minutes and 30 seconds) from the time of curation and the time the agent picked up the curated record.
In the case where the staging record was curated at 6:02:00 precisely in the database, then the agent 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 agent 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 agent receives the update from the database, delayed by approximately 10 minutes to return data from staged to agent.
The net delay is approximately 17 minutes from the time the data is updated in the production database, staged, and returned to the agent.