CQL++ will restore the database to a consistent state, provided the transaction logs are intact. There are two issues that impact the reliability of the transaction logs.

First, there has to be enough room in the logs to completely contain the data for the largest expected transaction. There are two configuration parameters that affect this. The number of transaction logs (default 4), and the maximum size of each transaction log (default 10 MB). If you have extremely large transactions, you may need to increase the maximum size, the number of logs, or both. Note that the temporal length of a transaction is not the most important issue. Log space is consumed by data inserts, updates, and deletes.

In client/server mode, the issue is a bit more subtle, because any connected application has the potential for consuming the available log space, and thus interfering with the recoverability of a transaction belonging to a different application.

Currently, the logs do not resize dynamically. The system will detect that a log space overrun has occurred, but will not at that point be able to continue, and the uncommitted data may be lost.

The other issue with transaction logging involves operating system buffering of the transaction logs. CQL++ has a separate set of calls used to open, read, and write log files. This provides the flexibility to implement system specific code required to defeat operating system cacheing and flush log file writes to physical disk. The methods for accomplishing this are system specific, and the user needs to examine this issue for each environment where CQL++ is used and where guaranteed crash recovery is required. We can provide instructions on how to defeat O/S buffering for some systems.

Note also that there are two types of buffering. C (C++) calls to flush data to disk flush data from the library's cache to the operating system. These calls do not flush the data from operating system caches to physical disk. Thus caching at the O/S level MUST be turned off for log files, or special handling of the log writes must be implemented, in order to guarantee recoverability.

If the logs are not intact, there is no guarantee of recoverability.

Currently, CQL++ does not have the ability to write duplicate logs. We will be adding this in a future release. If this is a critical issue for you, we can show you how to add this feature or add it on a contract basis. We don't have even an approximate target date for implementing this feature yet. Our closest estimate is that it will be released before the end of the year.