As a follow up to your last post I have a few questions that would help with us with understanding what is going on behind the scenes inside object db.
When you refer to having "30 open databases", are you talking about having 30 PersistanceManagers open? Or 30 PersistanceManagerFactories? Or is it one and the same? We are creating a new PM for each transaction currently, and are accessing the DB from different threads. It is not impossible to imagine that at any given time 30 or more persistance managers are active in the system and processing some data transactions.
When Does each PersistenceManager have its own 64mb processing cache? During what part of operation is another 64 mb cache allocated to the system?
Today, we ran some more tests. We wrote a very stripped down version of our embedded ObjectDB database application, that simply connects to the application that supplies our data and stores it in an .odb file. This application created a single PersistenceManagerFactory which had a thread pool of 10 threads each of which could be called to process data for storage by getting a new PersistanceManager from the factory, and storing the persistable objects using the manager. At the end of the threads run, the PM was closed.
When we ran this test, only one thread was required tp handle processing and storage of the data - a second thread was never requested from the pool. Again we noted that when indexing was enabled on a unique String field, our memory usage was far higher than when an index was not specified.During the runs of the code, the memory usage followed a linear trajectory until the application ran out of heap space and crashed.
During both runs with indexing and without, the object that JVisualVM showed as the biggest memory user was byte arrays - usually hitting between 75-90% of the memory in use . Is this normal?
Thank you again for your help, it is greatly appreciated.