Potential improvement: documentation warnings and safer defaults in case of issues while storing

[AndreaPravato]

Is your feature request related to a problem? Please describe.

In the rare case of the running application having issues writing to filesystem on storageManager.store(object) (..or for any other error during that kind of activity), end users could read ram data that is not persisted yet [and by Hyrum's law, the observable behavior of the system risks to be depended on by somebody], with that data being reverted back to previous state on next application start (loading data from filesystem).

Describe the solution you'd like

A first important intervention to mitigate the potential issue could be enhancing the documentation (e.g. https://docs.eclipsestore.io/manual/storage/storing-data/index.html) by describing the potential issue and providing samples of protection. The developer should be aware of the potential problem and actively protect with something like the wrapper store method found here, which has a try catch and a kind of shutdown (https://github.com/ZorgCK/MSTraining_ExeptionHandling/blob/exceptionhandling_bestpractice_done/src/main/java/one/microstream/storage/DB.java), or alternatively a catch and the reloader, or somehow lock that data etc. I feel, in case of issues while writing to filesystem, stopping the storageManager (and maybe even the whole application?), besides throwing the error, should ideally be the default framework behaviour, since it looks safer (preventing new reads, at least from storage) [or, if conveniently feasible, block/remove just that data from ram]. A related config option could be provided to alter the new default behavior, or a parameter passed to the store method, in case for example somebody wants to continue execution and use the reloader to realign ram with disk data in the catch

Describe alternatives you've considered

I guess enhancing documentation is suitable. The fact that the storagemanager is already throwing an error is already good. Subjectively, but I recognize it is debatable, I feel for such a critical condition the framework behavior could be changed to a more protective default.

[AndreaPravato]

Related to previous point, also usage of the store without having a root attached (.createEmbeddedStorageManager(root)) could be prevented by default / warned-about (application will run, but on next start previously "stored" data will not be available)

[hg-ms]

Hi improving the documentation of storage error behavior is a good idea we should do that. Regarding a not attached root you do check in the application code:

//start StorageManager
EmbeddedStorageManager storage = EmbeddedStorage.start();
//check for user root
if(storage.root() == null) {
    //no user root set
}