Hello Origon45,
First of all thank you very much for your detailed answer :) Some of the things you said already helped us a bit, and your answer was encouraging.
If you don't mind, I would like to explain again how why are using db4o. We are only using it as a backup mechanism to write memory objects to disk. We create a database file, write 1 big, complex object, with many smaller objects inside, and close the database.
The database file is never updated or opened again, except when the developers want to inspect the data to look for problems.
The application works in RAM only all the time except when we make a backup of the data in RAM (and the data in RAM is locked until it is written completely to disk). For reference, the database files are around 4MB when written to disk.
Answering your questions: (with more questions sometimes :) )
1. We are using a heap of 256 MB. The test server we are currently using has only 512 MB of RAM. The application uses around 60MB of RAM most of the time, but there are peaks of memory usage that cause trouble (for ex. when storing the backup of the data in memory). Of course, this is a very small amount of memory. But the tests we are performing have a low number of users (300) compared to what we expect later. We think we have to solve the problem with only 300 users and 256MB of heap, because if we just put more RAM in the machine, the problem will come back later anyway with a bigger number of users.
2. We are not using indexes at all right now. Would they be helpful in this situation? I think indexes would help when querying or updating the database. Are they helpful for just writing objects once? The object that we are storing has actually many 'user' objects inside. Indexing these objects would help using less RAM for storing them?
3. It is not 100% necessary to save one big object, but it helps us. Actually, we are simplifying the object graph right now, by eliminating references between objects and storing IDs instead. We hope this will simplify db4o's task when storing the data.
4. This is roughly how we store the object:
ObjectContainer db = null;
db = Db4o.openFile(path);
db.set(complicatedObject);
db.commit();
db.close();
As you see, very simple code and no complications at all. Except for the fact that the stored object has a complex structure, with many many objects, of different classes, and in great number, inside.
David