|
|
|
Background Flushes
When all threads are idle, FairCom DB flushes the cache in the background (unless any activity is detected).
Every 15 seconds (a configurable interval), a thread checks to see if the system is idle and, if so, flushes the cache. This operation is designed to yield to any activity. Additionally, the cache is flushed when any of these events occur:
FairCom DB flushes data and index caches during idle time via idle thread processes. Transaction-controlled files are flushed by one thread, while non-transaction controlled files are flushed by another. These threads periodically wake and, if FairCom DB is idle, begin flushing. Subsequent activity terminates the flush so that it does not impact performance. For complete control, the wake-up timing is configurable and the threads can be disabled.
It is important to note that the background flushes are designed to yield to any other server activity. As such, you should not count on them to keep your data written to disk.
KEEPOPEN Files
When using the KEEPOPEN keyword, the file is stays open and any updated data remains in FairCom DB Server's cache. In this case, do not expect all the data to be in file system cache or on disk at the time that the file close call returns to the client. Files using KEEPOPEN can be flushed to disk by the idle flush threads or by calling CtreeFlushFile().
Transaction Control
When a file is under transaction control, completed transactions are written to log files. These transaction log files are flushed to disk when the transaction is committed or when a save point is reached. The transaction is held in temporary PreImage memory until it is written to the log file.
The configuration keyword COMPATIBILITY LOG_WRITETHRU can result in performance gains without sacrificing recoverability. Without this keyword, individual transactions are written to the file system cache and then flushed to disk periodically. This can impact performance while the data is being written to disk. When this keyword is used, transactions are written to the file system cache then to disk. Although this may impact performance on each transaction, it avoids the bottleneck of writing a large number of transactions to disk.
Similarly, COMPATIBILITY TDATA_WRITETHRU and COMPATIBILITY TINDEX_WRITETHRU force transaction-controlled data files and index files, respectively, to be written directly to disk.
