Transaction

ODB uses transactions to guarantee database integrity (ACID properties).

When an ODB database is opened, a session (org.neodatis.odb.core.session.Session) is automatically created. The session contains a special object, a org.neodatis.odb.core.acid.Transaction.

The Transaction object manage all the data and behaviour of the current Transaction.

When executing an operation (insert, update, delete, …) that modifies the database, some parts of the operation can be directly written to the database file (see Buffers for IO performance) other can not.

Example:

When inserting a new object, the object can be written directly to the database but references to this object can not. In this case, references are written in the transaction (as a list of org.neodatis.odb.core.acid.WriteAction).

So basically, ODB is being optimistic and write almost everything to the database. Only pointers and data from update and delete are written in the Transaction File. The writing in Transaction file begins as soon as the implicit transaction is created by ODB. On commit, the transaction content is applied to main database file.

The Transaction keep a list of WriteAction (that contain data that can not be written directly) in memory and in a special file (extension .transaction). On Commit, if all Write Actions are on memory, ODB simply apply them to the database file. If not, ODB first loads them from the transaction file and then apply them to the database file. After commit, the transaction file is deleted. On failure, the transaction file remains on the disk and already written objects remain in the ODB database file but without any reference to them so they do not exist for the database.

Commit Process

The database can be divided into 2 different zones:

  • Commited Zone
  • Uncommited (Unconnected) zone

The commited zone contains all commited work!
Uncommited zone contains all the work that has not been commited yet,work of open transactions.

All new objects&modifications must be created in the uncommitted zone.

Uncommited zone can be divided in 2 sub-one:

  • Unconnected Zone: New objects Zone
  • Connected Zone:Modifications Zone

The Unconnected Zone contains all the new objects without any link(pointers)from the commited zone.All new objects are actually written in the database file. And will stay in the database in case of rollback but they will be unreachable so it will not bring inconsistency!

The Connected Zone contains Write Actions (that represents object updates and deletes) that will be applied to the commited zone when commited.

When commiting:

  • Uncommited Transaction Zone:all first new objects must be connected to last commited objects (previous object OID and next object OID). This must be done for all new objects types.
  • Connected TransactionZone: WriteActions must be applied to the commited zone.

The commit operation must use a Storage Engine Scope Mutex.

Example: 3 concurrent sessions

**Session 1: **

  • creates 1 new user using Profile P1
  • creates 2 new Functions F4 and F5

Session 2:

  • creates 1 new Function F6
  • modifies the name of Profile P1

Session 3:

  • creates a new Profile P3 and updates User U1 with P3

Commit:

Commiting Session1:

  1. Take mutex
  2. Connect U2 and U3
  3. Update User ClassInfo nb=nb+1,last object position=position(U3)
  4. Connect F3 and F4
  5. Update Function ClassInfo nb=nb+2,last object position=position(F5)
  6. Release Mutex

commiting Session2:

  1. Take mutex
  2. Connect F5 and F6
  3. Update Function ClassInfo nb=nb+1,last object position=position(F6)
  4. Apply WriteAction
  5. Release Mutex

The commited base and the 3 sessions

commit-1.png

Commiting the session 1 in red

Link objects of Unconnected Zone to the commited zone:

commit-2.png

Commiting Session 2 in green

commit-3.png

Commiting Session 3 in blue

commit-4.png
Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License