Nick Puz wrote:
I've been doing performance evaluation of derby for a potential project (using dtrace on osx and sun) and noticed that recovery is still run after doing what I thought was a clean shutdown. I've stepped through derby10.4 (svn rev 751303) with java 6 and can see that recovery is being run and the three operations being applied are: start tx, checkpoint, then endtx.
Attached is a test program and copy of the dtrace output (showing file
operations). The test program:
1) opens a connection to the db then closes it.
2) shuts down the db by opening a connection with ";shutdown=true" added to the
url.
3) prompts for input (to add spacing to dtrace output/ start tracing)
4) repeats steps 1 & 2 -- starts on line 236 of attached dtrace output.
Is there a way to close the DB to avoid the subsequent recovery actions on
open? Not so much the recovery (i understand it has to check on startup) but
the write/fsync of the log, log.ctrl, and logmirror.ctrl.
The recovery algorithm will always be executed when you boot a database,
even when you have performed a clean shutdown like you have. Thus, the
{start tx, checkpoint, commit} sequence is the least amount of recovery
work currently possible in Derby.
AFAIK, there's no way to avoid this sequence - I don't think anyone ever
considered writing a single block to disk at boot time would be a problem.
You may consider adding a bug report about this if it causes problems
for you. Writing a patch for it would be even better if it is important
to you :-)
BTW: should you consider working on this issue, the commit is what
causes the write to disk. The checkpoint does nothing in this case.
--
Jørgen Løland
