Commit Records and Transaction Logs

CommitRecords

A transaction can be considered a boundary that defines a collection of changes made to a group of objects. All of these changes in conjunction with the unique object ids of the affected objects as well as various other housekeeping objects are accumulated in a repository page called a CommitRecord.

Each CommitRecord represents a view of the repository and it takes both CPU resources and memory resources to manage these views. If a transaction takes too long too complete either because there are a large number of objects to process, or because the application code began a transaction and neglected to commit it, or the thread is waiting for other things to complete, then a large number of CommitRecords can start to build up. This buildup of CommitRecords can cause repository growth because Facets cannot recycle the pages used to represent views of the old transactions. It can also can degrade performance because the shared memory cache is too small to hold all of the views. Hence it is important to ensure that transactions are commited or aborted as soon as possible.

Transaction Logs

Before a transaction can be considered committed, the changes must be written to a Transaction log to ensure that they can be recovered. Transaction logs are vital to the resilience of your repository. Every so often Facets will checkpoint, and when it does so the pages currently in memory that have been changed will be flushed to disk to ensure their persistence. However, under unusual circumstances, a power failure or a system administrator error could cause Facets to be shut down some time after the last checkpoint, but before the next one has completed. In this case the respository will only be up-to-date at the point when it was last checkpointed. The transaction logs are used in a case like this to recover all the unflushed changes, and for this reason, are vital to system health. Making the time between your checkpoints longer can improve the performance of Facets. It is always important that transaction logs are situated on disks that perform well and can be safely recovered in the event of hardware failure, since they are your link to recovery.

In the event that you are designing a high performance system using Facets it is advisable to contact Gemstone for advice on the configuration of your checkpoints and transaction logs as well as the disks that they are located on. Correct disk and hardware configuration can be pivotal to making Facets performance exceed expectations rather than just being good.

Commit Record Counts

In module 14, we cover the statistics that can be used to monitor and tune a Facets system. The outstanding number of CommitRecords, known as the Commit Record Count is a major indicator of the health of your Facets system under load, and the VSD (Visual Statistics Display) can be used to monitor this value on a real time basis. Administrators requiring high performance should make use of this tool to keep an eye on the Commit Record Count during peak usage.