db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bryan Pendleton <bpendle...@amberpoint.com>
Subject Re: Forcing Data to Disk on JPA Commit
Date Wed, 12 Dec 2007 15:16:17 GMT
> 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.



View raw message