Atomicity of updates, roll backs, and what happens to indexes when a rollback happens are covered in this document.
The store database, RDbStoreDatabase, runs completely
client side and requires the user program to provide a store for its operations.
For this reason, isolation, concurrency and serializability are not issues
for the transaction model. However, support for multiple rowsets concurrently
updating the same table is provided, and the rowset cursors attempt to maintain
their current position through such (potentially conflicting) updates.
Transactions on a store database do guarantee atomicity of updates. As RDbStoreDatabase is
designed to be a small-scale relational database, it does not make sense for
it to use transaction systems more suited to large server hosted databases.
Instead of using a logfile, the store database provides transaction support
by using the commit and revert functionality of CStreamStore.
If the actual store class does not support this protocol, then it cannot be
used as a basis for a DBMS store database. Practically, this means that store
databases are permanent file stores, i.e. CPermanentFileStore.
Successful transaction support by RDbStoreDatabase requires
that the client must not call CommitL() and Revert() on
the store while the database is open. Should a client need to modify its
own stream data using the store's commit/revert protocol while a database
is open, it can enclose the stream operations within a database transaction,
using rollback on error; this achieves an equivalent result. Such store operations
can be combined with database updates within a transaction to ensure that
the separate updates are treated atomically.
Committing a transaction leaves all open rowsets in a valid state. How and when updates are reflected within those rowsets depends on how they have been evaluated.
Rolling back a transaction causes all rowsets on the database to lose their current place. All rowsets must be reset and possibly be re-evaluated before they can be used again. However, they do not need to be opened or prepared again.
Indexes cannot be recovered easily on rollback, so they are marked as unusable, and the database is marked as damaged. Tables and untouched indexes continue to operate as before. Recovering the database restores the damaged indexes fully.
For multiple updates, explicitly using a transaction can also reduce the time required by a factor of more than 50. It also reduces the transient store size requirement by a factor of more than 6 — compaction of the store results in similar sizes for updates whether or not a transaction was used.