As a database storage engine, the SSM provides the atomicity, consistency, isolation, and durability (often referred to as ACID) properties associated with transactions. More information on transaction processing issues can be found in the book Transaction Processing: concepts and techniques [GrRe].
A transaction bounds an atomic and set of operations on records, files, and indexes. The manual page, transaction(ssm), describes methods for beginning, committing and aborting transactions. Updates made by committed transactions are guaranteed to be reflected on stable storage, even in the event of software or processor failure. Updates made by aborted transactions are rolled back and are not reflected on stable storage.
Although nested transactions are not provided at this time, the notion of save-points are. Save-points delineate a set of operations that can be rolled back without rolling back the entire transaction. The interface is described in transaction(ssm).
Transactions are also a unit if isolation. Locking is provided by the SSM as a way to keep one transaction from interfering with another. When designing the SSM interface there was considerable debate on whether the SSM should automatically do locking or instead require the VAS writer to obtain appropriate locks. We chose to have the SSM automatically obtain locks, but the SSM interface does provide methods allowing locks to be explicitly acquired. See lock(ssm) for details.
The SSM performs concurrency control using the standard hierarchical two-phase locking protocol [GrRe]. The lock hierarchy for files is: volume, file, page, slot-containing-record. The lock hierarchy for indexes is: volume, index, key-value.
Chained transactions are also provided. Chaining involves committing a transaction, retaining its locks, starting a new transaction and giving the locks to the new transaction.