TurboDB Engine Documentation


Previous  Top  Next

TurboDB supports transactions based on an additional storage object per table, the redo-log. When an transaction is started, all subsequent modification to the database tables will be entered in the redo-logs after they have been materialized to disk. If the transaction is committed, the redo-log is simply deleted. If the transaction is rolled-back, the information from the redo-log is used to undo the modifications. This means, TurboDB follows an optimistic transaction schema: Committing a transaction is very fast, while undoing it, requires much more work.

The tables, which have been modified by the transaction are locked to other sessions until the transaction is finished. For performance reasons, tables, which have been read during the transaction are not locked. Therefore the transaction level in TurboDB is read-committed.

Because TurboDB clients can interact on file level (i.e. without a database server), the handling of clients that die during a transaction is more difficult. TurboDB engine can detect the fact, that another client has died and performs the roll-back. Because in the scenario, another client undoes the modifications of the died client, we call this mechanism hijacking.