Derby does not guarantee atomicity? Other java DB's? I thought they did,
but perhaps not. You cannot rig a simple system with some sort of rename
call?
If a hard power shutdown interrupted, on the next start the system could
ideally be left in a condition that uses the previous commit point, or
recognize the latest commit failed, clean it up, and go back to the
previous commit point. There must be ways to do it that don't rely on a
buffer being fully flushed, but rather on atomic file system operations
(of which there must be some that can be counted on in java?).
Chris Hostetter wrote:
: Is the new autocommit=false code atomic (the new check point is successfully
: made and moved to or its not)? If not I imagine it could be made to be without
: too much work right?
No matter what work we do in Java code to try and garuntee atomicity, the
JVM can't garuntee that File IO buffers are flushed unless the JVM is
shutdown cleanly, so i don't see how we could possibly make any claims
of atomicity in the event of hard process (or OS) termination.
i'd be happy to be proven wrong by someone who knows more about IO,
filesystems, and the JVM Specification.
-Hoss
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
