Appendix C: RealTime database (RTDB) configuration settings

Note: For information on overriding default configuration settings, refer to Modify configuration settings.

The following list of configuration settings are used to modify the behavior of the RealTime database (RTDB) locking functionality. These settings reside in %DNAInstallRoot%\RealTime\config\Settings\RealTime_Database.json.

Double-Buffering Support

The double-buffering functionality in the RealTime product is a mechanism designed to reduce lock contention in cases where multiple processes may be attempting to access the same RTDB table record. In such cases, without double-buffering, a process must wait for whatever process is currently acting on (reading or writing) a record to complete its activity before it can access that record.

With double-buffering enabled, the system holds two copies of each record in memory instead of a single copy. One copy is used for read operations; the other for write operations. Once a write operation completes, the system swaps the two buffers and readers then have access to the newly updated version of the record. Writes are the only blocking operation, and the system will only block other writers. An in-progress write operation will not block readers, nor will one reader block another reader.

Notes: Double-buffering functionality results in the RTDB using a larger memory footprint for those tables being double-buffered. This is the trade-off for the reduction in locking contention provided by this functionality.

The structure of the double-buffering configuration in the RealTime_Database.json file is as follows:

{

"RealTime": {

"DoubleBufferingSupport": {

"Enabled": false,

"ExcludedTables": [

"pipeline",

"adetect",

"anomaly",

"batch",

"connectivity",

"detect",

"eta",

"fragment",

"node",

"pipe_segment",

"section",

"plm",

"plmvoldevice",

]

}

}

}

Note: The default list of excluded tables supplied in the RealTime_Database.json file do not currently support double-buffering because they employ a non-standard parent-child locking methodology. The applications that use these tables manage locks in a non-standard way in order to facilitate more complex data relationships. AVEVA recommends consulting the OASyS R&D Architecture team prior to making any changes to this list.