By default, OrigoDB transactions are serialized providing perfect isolation and the strictest possible consistency. Command and query execution (writes and reads) are the implicit transactional units. The thread safe Engine is responsible for proper transaction management. Explicit transactions are not supported, nor are they necessary.
If a command fails with an unexpected exception, the in-memory model will be restored to the state prior to the failing command.
Serialized isolation guarantees the strongest possible consistency.
Commands are executed sequentially, thus fully isolated. The default
ISynchronizer uses a
ReaderWriterLockSlim to allow either a single writer or multiple readers at any given time. This guarantees that reads always see the most recent state (and that the state is not modified) for the entire duration of the transaction. By default, query results are cloned to prevent accidentally returning references to mutable objects within the model.
Commands are written and flushed to the journal before execution, also known as write ahead logging.
OrigoDB supports the MVCC concurrency model. With this model, writes are serialized but will not block reads, which use snapshot isolation. Snapshots are based on the most recently committed write transaction. See the section on Immutability for details.
There are no explicit transactions in OrigoDB. You cannot begin a transaction, make changes, then commit or rollback. Relational databases use the rollback mechanism to resolve conflicting changes caused by concurrent transactions. OrigoDB does not have concurrent transactions so there is no need for explicit transactions. If you need to perform multiple commands as a single atomic unit, consider using the composite command pattern which batches multiple commands in a single transaction:
Command.Prepare()because it will not block readers