|
You can choose your recovery point in UltraLite by delaying committed transaction flushes. By choosing your own application recovery points you can better control when a subset of SQL statements in a transaction or unit of work trigger additional operational overhead when UltraLite releases the commit to storage.
In UltraLite, you can flush committed transactions individually or as a group.
By default, UltraLite uses an operational-based approach that flushes individual transactions to storage upon a commit immediately. For some deployments, this can be excessive and limit the amount of transaction throughput.
To reduce the performance expense caused by this operational-based default, some deployments may choose a state-based approach to delay the additional overhead required to flush the committed transactions to storage—especially for applications that rely on autocommit operations:
On checkpoint You can set your own checkpoint, and then use it to release the work performed over that course of time. You can use as many checkpoints as you require, either within a single transaction or over multiple transactions.
Grouped You can choose a transaction count threshold and/or a timeout threshold to release the work performed.
Delaying commit flushes based on state yields better performance and a cleaner application design compared to flush transactions to storage immediately. In terms of performance, applications are not required to wait for a response from UltraLite. This lag between commit and response can have considerable impact on scanning-type applications that rely on UltraLite to manage those transactions.
By delaying commit flushes you also minimize the exposure to transactions, by giving more granular control over data for which work has not been fully completed. For example, in a sales application, an order may be available to a second application before all items have been added or even approved.
However, it is important for you to take into account the recoverability of a transaction for which commit flushes have been delayed. Transactions that have not been released cannot be recovered. Therefore, you need to evaluate the tradeoff between the data integrity of your application and its performance.