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.