This is simple not true. See FileDescriptor.sync().
There are several options, but normally it is used so that when close
completes, all data must be on disk. This is a much slower way to
write data. It is very common in database systems when committing the
log file.
By using this, and proper file naming techniques full transaction
integrity can be GUARANTEED in Java.
See the BerkleyDB, or Derby for other examples.
On Nov 3, 2007, at 6:56 PM, 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]
