sorry, but I'm not convinced that your suggestions will scale with db4o even in a simple web-application...
I have to disagree with you here Maik, although the performance might be better due to not opening and closing connections, this is a scary proposition that takes a lot more work on the app developers side since they now have to be aware that there is long running connections/transactions.
That's the price you have to pay if you're using db4o. The application developer has to think about different issues when he is going to use db4o in a proper way, because using db4o is simply "a little bit different".
For example: Usually a web-application developer doesn't have to think about referential integrity regarding the database. With db4o, he needs to. And there are lots of other areas where the common patterns of databased-web-application-development doesn't work out for db4o.
It's a common deFacto standard to use a connection-per-request (CPR) and using a connection pool with CPR should give great performance because you reuse connections and keep the total connection count down.
The deFacto standard is to use a RDBMS for building wep-applications. So what is the thing about deFacto standards? Maybe we have to establish different standards to make real use of db4o...
Storing the connection in the user session means that you would be holding a connection open for a long period of time (30 minutes or whatever they set the session timeout to) until it can get cleaned up. If you do hold it in the session, then you'll need to implement a Session listener to close the ObjectContainer when the session is destroyed.
Implementing such a SessionListener is a no-brainer, isn't it? Have a look at the following article in the db4o-Knowledge-Base, which simply suggests to store an ObjectClient in the session if you can't go with sharedTransaction:
#sharedTransaction() vs. #sessionTransaction() when working with servlets
Maybe this article should be updated to reflect your concerns about storing an ObjectClient within a session?
And what if you have 1000 users? You'd have 1000 open connections to the database, most of which are probably barely utilized.
If you have 1000 users hitting your application again and again within seconds (or minutes), you'll experience lots of other problems with db4o...
BTW: Can you explain what's the problem (in terms of costs) with open connections for a db4o-server running in "embedded" mode (with no TCP/IP involved)?
The only reason I can think that you'd would ever really want keep an ObjectContainer open for longer than a request is if you have some kind of long transaction that cannot be commited after a single user interaction.
Reusing already cached objects can be another important benefit I can think of. Utilizing more memory is a simple and cheap solution to scale an application backed by an object-database.