Feature Request for database.obj$ file

I've two questions and maybe feature requests regarding the $file.

a) is there a valid method to check when everything is done after closing the database?

background:

As far as we recognized there is a background thread, merging the database.obj and the database.obj§ files.
As long as this daemon thread is running we could not shutdown the application. For now we helped us looking out for a corresponding database.ojb$ file. But of course we could not wait for ever so there is a timeout wich is 3 minutes per default.

which leads me to the next question:

b) is there a way to automaticly force a write (or flush) from the database.obj$ file to database.obj
during an opened database connection?
Especially when the whole system is idle it should be a good idea.

background:

big databases (5GB and more) tend to have big $files even if nobody is working for hours. That means if an automatic restart should be done (default at 3 am) it takes a lot of time shutting down and sometimes it even takes longer than 3 minutes.We could avoid this if a flush of a database.obj$ file is possible.

thanks and best regards
Arne

>  a) is there a valid method to check when everything is done after closing the database?

Closing the EntityManagerFactory should complete this synchronously, so basically when the close method returns the odb$ file should be gone. Have you experienced scenarios in which after ordinary close (of the EntityManagerFactory, not just the EntityManager) the odb$ file still exists?

> b) is there a way to automatically force a write (or flush) from the database.obj$ file to database.obj
during an opened database connection?

The background thread should do its work automatically, particularly when the system is idle. If it doesn't it might be because a user holds a snapshot of the database for a long time (i.e. an EntityManager after flush that is not closed). It is a good practice to use a long-lived EntityManagerFactory but short-lived EntityManager connections. Check if you have an EntityManager that is open for hours.

> sometimes it even takes longer than 3 minutes.

That seems unusual and may require further investigation. What is the size of the recovery file in that case?

Question: Why do you do that checks rather than just restarting with or without the odb$ file?

thanks for responding and sorry for delay

>> Question: Why do you do that checks rather than just restarting with or without the odb$ file?

The server is running as daemon/ service in embedded mode and was started and stopped either by a deamonmanager or a dockermanager. The main reason is, that we shut down the server once a day. Meanwhile our customers might do some backups - in addition to the serverside triggered backup with createQuery("objectdb backup").

I have no glue what might happen to the data$ if the deamon process was stopped while flushing is in progress but finally we want to know when the server and all connected services are correctly stopped.

For the your first question I still try to create a testcase wich might reproduce the situation. Typically we have  one long-term EntityManagerFactory and a lot of stateless short-term EntityManagers. I'm not totally sure if there is even a long-term EntityManager with maybe some background duty, i will look on it. If there is one could this cause the behavior?

So first I will try to create a testcase and then report back

best regards
Arne

> what might happen to the data$ if the deamon process was stopped while flushing is in progress

ObjectDB should proceed from that point when restarted. However, obviously it is good practice and possibly safer to have ordinary close that deletes the odb$ file.

> If there is one could this cause the behavior?

Yes. ObjectDB supports multiple snapshots of the database for multiple connections (representing by EntityManager instances) by delaying changes to the main database file, so the oldest snapshot uses only the main database file and following snapshots use combinations of page versions from the main database file and the $ file.

> So first I will try to create a testcase and then report back

That can help.