You are here: Basics Operations & Concepts > ACID Properties And Transactions > db4o's Commit Process

db4o's Commit Process

How does db4o make transactions safe, so that it can recover failures? Here's the short overview of the transaction-phases db4o uses.

Phase In Case Of A Crash
1. During the transactions. New and updated objects are written to a new Slot in the database-file. The id-mapping and freespace changes are kept in the transaction. The changes are lost, because the id-mapping and freespace changes weren't persisted. Therefore the changes are invisible to the database. The transaction is rolled back.
2. Committing starts: The id-changes and free-space changes are written to a new slot, without damaging the old information. The changes are lost, because the id-mapping and freespace changes haven't been completely stored. The transaction is rolled back.
3. Write the location of latest id-records, and free-space changes to the first location with and additional checksum. If the record write was completed, the transaction is resumed and completed. If not, the old information is used.
4. Write the of latest id-recods, and free-space changes to the backup location with and additional checksum. If the record wasn't completely written, the transaction is resumed.

Of course you don't need to worry about this. db4o ensures that a transaction either completes or is rolled back. Whenever you call commit and the call succeeds, all changes are persisted. If your application or db4o crashes before a successfully commit-call, all changes are undone.