8. TransactionsProbably you have already wondered how db4o handles concurrent access to a single database. Just as any other DBMS, db4o provides a transaction mechanism. Before we take a look at multiple, perhaps even remote, clients accessing a db4o instance in parallel, we will introduce db4o transaction concepts in isolation. 8.1. Commit and rollbackYou may not have noticed it, but we have already been working with transactions from the first chapter on. By definition, you are always working inside a transaction when interacting with db4o. A transaction is implicitly started when you open a container, and the current transaction is implicitly committed when you close it again. So the following code snippet to store a car is semantically identical to the ones we have seen before; it just makes the commit explicit.
However, we can also rollback the current transaction, resetting the state of our database to the last commit point.
8.2. Refresh live objectsThere's one problem, though: We can roll back our database, but this cannot automagically trigger a rollback for our live objects.
We will have to explicitly refresh our live objects when we suspect they may have participated in a rollback transaction.
What is this IExtObjectContainer construct good for? Well, it provides some functionality that is in itself stable, but the API may still be subject to change. As soon as we are confident that no more changes will occur, ext functionality will be transferred to the common IObjectContainer API. Finally, we clean up again.
8.3. ConclusionWe have seen how transactions work for a single client. In the Client/Server chapter we will see how the transaction concept extends to multiple clients, whether they are located within the same runtime or on a remote machine. Let't first revisit Activation again in the next chapter and take a look at how db4o can take care of our Object lifecycle automatically. 8.4. Full source
|