Do I have to re-apply db4o configuration settings (and indexes) on each application run, or only on database creation?

Just as an FYI, there is an exception .. indexes once created are saved and will be used regardless of their specification at OpenFile/Connection time Best, Robert.

Just as an FYI, there is an exception .. indexes once created are saved and will be used regardless of their specification at OpenFile/Connection time. Best, Robert.

Awesome, that's good to know. I have no problem with the configuration being set at load time but was getting a little worried about db4o re-indexing every time the database was loaded. Glad to know that's not the case!

– Jason L. Dec 7 '10 at 19:16.

After more digging in the documentation for db4o I found my answer :) "Configuration settings are not stored in db4o database files. Accordingly the same configuration has to be submitted every time an ObjectContainer/ObjectServer is opened. For using db4o in client/server mode it is recommended to use the same configuration on the server and on the client.To set this up nicely it makes sense to create one application class with one method that creates an appropriate configuration and to deploy this class both to the server and to all clients.

1 That's true in general. But there are a few exceptions. One of them are indexes, which are persistent.

However I would recommend to still configure indexes on every startup, just for documentations-sake. If you add the index to your configuration every time it just will use the existing index or create one otherwise. – Gamlor Dec 11 '10 at 8:34.

We're evaluating db4o (an OO-DBMS from http://www.db4o.com). We've put together a performance test for client/server mode, where we spin up a server, then hammer it with several clients at once. It seems like the server can only process one client's query at a time.

Have we missed a configuration switch somewhere that allows for this scenario? Server implementation is below. The client connects, queries (read-only), and disconnects per operation, and operations run one immediately after the other from several worker threads in the client process.

We see same behaviour if we spin up one client process with one worker each against the same server. Edit: We've now discovered, and tried out, the Lazy and Snapshot QueryModes, and although this alleviates the blocking server problem (partially), we still see significant concurrency problems when our clients (we run 40 concurrent test-clients that wait 1-300ms before issuing a random operation-request) hammer on the server.

I cant really gove you an answer,but what I can give you is a way to a solution, that is you have to find the anglde that you relate to or peaks your interest. A good paper is one that people get drawn into because it reaches them ln some way.As for me WW11 to me, I think of the holocaust and the effect it had on the survivors, their families and those who stood by and did nothing until it was too late.

Related Questions