See my previous email.
I have written several 'atomic' ACID systems in java. It is VERY EASY
TO DO. Read any introductory (academic) book on database systems.
On Nov 3, 2007, at 7:08 PM, Mark Miller wrote:
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
