Multiple Containers read/write access in multi-threaded environment

Question

I'm been reading the Berkeley DB XML Transaction Processing document and have a few questions. I have a multi-threaded environment (not multi-process).
1) In the "Summary and Examples" section, there is an example of several worker threads that perform many writes to a shared container. The one container is passed to all the worker threads, rather them having their own instance of the container. In my application, I could potentially have multiple worker threads acting on the same container, is it better to provide some type of connection pool, so each thread has access to the same container? Is their a problem with each thread creating a new instance of the container and writing to that? Is their pros and cons to each approach?
2) In some specific web applications, they only require read-access and have no intention of writing to the database. If the environment was created with transactions, can these applications open the environment in read-only mode, so as to not suffer the performance penalty of using transactions? Or do they still require transaction support since other threads in other applications might be writing to it. Is it better in this case to
3) Is there any decent connection pooling framework that work well with BDB XML? If transactions are involved, it seems pretty important to always close the container once you are finished with it, which kind of defeats the purpose of pooling. I see a container somewhat analogous to a JDBC transaction, where in connection pooling these transactions remain open, but in BDB XML, it doesn't seem like this is good practice. So clarification here would be appreciated.
Thanks in advance...
Chris

Answer 1

Chris,
I'd be careful about trying to draw too many analogies with other sorts of systems. In many ways BDB XML is simpler -- it's just a library, no server process.
An open container is analogous to an open file handle/descriptor in your operating system. It can safely be shared by all threads within a given process. In fact, you should not create more than one -- while that works, it can just be confusing, and a source of errors (for example, if you use a different path to open the container each time, you'll have problems). So by all means share them. Most Java applications just point them in a class that is accessible to all threads.
Other objects that can, and should be shared among threads include:
Environment
XmlManager
XmlQueryExpression
Most others should not. You also mention closing your containers -- there is no reason to close your active container objects until your application needs to shut down. A long-running application will want to use db_checkpoint (or equivalent) to ensure that modified pages are flushed from the transaction log to the database files, but that's about it.
As for concurrency, you obviously need transactions for concurrent write operations. If you want concurrent read access to the same containers, they should use transactions as well. Even if you don't explicitly use transactions, locks are always taken on pages in transactional containers. You cannot open the same container transactionally and not transactionally at the same time -- bad things could happen.
Depending on your performance needs, you could using snapshot concurrency, and see how it works for you. While locking does incur some overhead, it may be acceptable.
You mention creating your own "snapshot" of a container and running read-only on that copy. That's possible to do, but you have to be careful of how you create the snapshot (following hot backup procedures). Also, if you intend to open that "new" container in the same environment or application as the old one, you need to run a program on it to change its internal identification so Berkeley DB won't think it's the same file. That is, you can't just copy a container file to a new name and just open it like it's a new container if it's still in the vicinity of the original. See the -r option for the db_load program.
Now that you are probably really confused, good luck!
Regards,
George