FairCom RTG V2 Update Guide

Expect Faster Application Throughput from Automatic Transaction Optimization

Transaction control is one of the most important data integrity benefits FairCom RTG brings to existing COBOL applications. Adding transaction support with FairCom RTG is transparent to the application with easy local configurations. Data integrity is provided by security data to persisted storage as soon as it is committed to the database. That persistence introduces a slight performance hit. Due to the nature of the automatic transaction support, this performance hit can be significant in various use cases. FairCom RTG V3 has improved this area of automatic transaction performance.

FairCom RTG creates tables as transaction processing capable by default; however, FairCom RTG applications seldom complete taking advantage of transaction processing control. COBOL, by default, opens tables in such a way that explicit transactions do not apply to them. In these cases, FairCom RTG now includes logic to detect and force automatic transaction processing.

When a FairCom RTG client sends a request for an update to the server, the following happens:

1. The server begins the transaction.
2. The server performs the update.
3. The server commits the transaction.
4. The server replies to client with the result.
5. The server waits for the next client request.

To enable this improved transaction optimization, include the following in your local FairCom RTG configuration options (ctree.conf). This is disabled by default.

This optimization reduces the amount of time before the server answers back to the client after an update. The server replies to the client while it is committing the transaction (the commit does not need to complete before returning back to the client). Compare the following sequence of events when enabled:

1. The server begins the transaction.
2. The server performs the update.
3. The server replies to client with the result
4. The server commits the transaction.
5. The server waits for the next client request.

By reducing the amount of time before returning the answer to the client, this greatly improves application throughput.

This has the effect that the record is not exactly committed or aborted by the time the client operation instigating the automatic transaction to the server (add, delete, update) returns. In case of disaster recovery, this may cause the last record update to be lost if the "disaster" occurred after the answer has been received by the client and before the commit is executed by the server, an expectedly very rare event.

This optimization is similar to the DELAYED_DURABILITY configuration (set on the Server side in ctsrvr.cfg) as both guarantee transaction atomicity and consistency and not durability, meaning the last transaction may be lost in rare cases of system failure. Typical envisioned failure scenarios include out of storage space, out of memory conditions, and storage system integrity issues. In case of transaction failure, the FairCom RTG server logs a CTSTATUS.FCS message and shuts down in a controlled coordinated effort.