later. Obviously, the data is being cached, which is generally a good thing. However, when a power outage occurs, there's no time for the cache to be written to the database. Transactions that happened two weeks earlier were not written to the database
When a Derby transaction is committed, although the data pages may not be immediately written to disk, the log records for that transaction are immediately written to disk, before the commit finishes.
So if the power should fail, when Derby is later restarted, it will perform recovery, read the committed transaction data from the log, and re-do those transactions. The checkpoint mechanism that you read about in the Derby manual is simply a way to speed the recovery processing, by bounding the work that recovery may need to do should a system crash occur. The absence of a checkpoint does not affect the fundamental durability of a commit. If you are seeing changes which are lost following a system crash and restart, my first guess would be that your application (or the persistence layer in between your application and Derby) is failing to commit the transactions of interest, but rather is keeping those transactions open, causing them to be aborted, not redone, when the post-crash recovery processing occurs. thanks, bryan
