How should you deal with concurrent access to a db4o database? This chapter gives an overview and guidelines for dealing with that.
There are some basic rules which you should never break, otherwise strange effects due to race-condition can happen:
Never share an object-container instance across threads, nor share the data-objects across threads. That will almost certainly create race-conditions. The reason is that when you change objects, while other threads read them, you will get inconsistent views on the state of your data model.
Now how do you deal with concurrent operations? Well you need to use some kind of synchronization strategy.
You can avoid synchronization when you are using multiple object containers for different units of work. However you need to be aware to the isolation level db4o guarantees. See "Object Container per Unit of Work"
This is often used in web applications, where you have an object container per request.
In a desktop/mobile application you usually want to have one consistent view on your data model. Therefore it makes sense to use the same object container in the whole application. That ensures that we always get the same objects throughout the whole application. As long as you don't load of work to different threads, everything is fine.
However as soon as you start to do manipulations on the data model in different threads you need to synchronize these operations. See "Sharing an Object Container Across Threads"