Well I''ve done some digging and found that by default the embedded database does cache changes to disk, which is defaulted to 20 seconds. So if the server shuts down before then, your changes are lost. Additionally, what is being written to disk is merely a log of your changes since the last checkpoint or shutdown command was issued and those changes are not guaranteed to make into the database after it is recreated upon the next startup if either of those two commands are not executed properly.
The other thing that I noticed was that, despite the API''s being available to provide a clean shutdown of the server and therefore the database connection, there is no mechanism for actually performing a clean shutdown in the user interface or the daemon (which the GUI launches). The stop button merely kills the daemon thread. Frankly this is rather absurd, as regardless of whether you are using the embedded database or not, you are never going to get a clean disconnect from the database since the connection managers never get a chance to shut down properly. These are basic programming principals here people.
Considering how trivial it is to support clean shut downs of the server, I strongly urge the developers to enable this support.
So here are the issues so far:
1) Admin Page always shows settings as being saved successfully regardless of any errors that may have occurred or whether the database actually saved the changes.
2) The server never allows for a clean shut down, meaning data integrity is a big issue. <-- using the windows GUI
3) Changes to server settings using the embedded HSQLDB are never saved if the server shuts down before the default 20 second write-to-disk setting
4) Changes written to the embedded HSQLDB are never reliable due to the server never shutting down cleanly as per item #2
Message was edited by: dhm116 - clarified issue #2
