Question

I am evaluating db4o for persistence for a ASP .NET MVC project.

I am wondering how I should use the IObjectContainer in a web context with regards to object lifetime. As I see it, I can do one of the following:

1. Create the IObjectContainer at application startup and keep the same instance for the entire application lifetime.
2. Create one IObjectContainer per request.
3. Start a server, and get a client IObjectContainer for each database interaction.

What are the implications of these options, in terms of performance and concurrency ?

Since the database is locked when an IObjectContainer is opened, I am pretty sure that option 2) would get me some problems with concurrency – would this also be the case for option 1 ?

As I understand it, if I retrieve an object from an IObjectContainer, it must be saved by the same IObjectContainer instance – in order for db4o to identify it as being the same object. Therefore, If I choose option 3), I would have to retrieve the original object, make the necessary changes (copy data from a modified object), and then store it using the same IObjectContainer. Is this true ?

Answer 1

Option 1) can get you into serious trouble because you will effectively share a transaction amongst all requests. I don’t think that this is a feasible option.

As you already identified, option 3) is fraught with its own perils because you will have to keep track of object identity manually – a tedious and extremely error-prone task. This really destroys all the beauty of the object database. Also, from what I know the overhead of creating IObjectContainer is not small so this will be far too expensive.

This pretty much leaves us with option 2, which does not lock the database when opened in client-server mode as far as I know – where did you find that informaiton? So the best idea is to open an IObjectServer on application startup and open new a IObjectContainer per-request, or connect to a remote server using TCP per-request.