On 02/16/2011 02:15 PM, Philip Martin wrote:
Blair Zajac<bl...@orcaware.com> writes:
On 02/16/2011 08:44 AM, Philip Martin wrote:
So if the timing is just right it's possible for one Apache process to
start writing the transaction, for that process to stop, and for another
process to take over the commit. WANdisco observed problems on FSFS
where the transaction is synced at the end of the commit, not for each
http request. What ends up in the transaction probably depends on the
details of the kernel memory and disk caching, the system load, the
underlying OS filesystem, etc.
This is a concern when the repository is hosted on an NFS or other
network attached storage? If all the Apache processes are on the same
system, then I wouldn't expect any issues.
I don't agree. Just because the process has written data to a file
doesn't mean it will appear on disk if the process is killed. We would
need to call fsync before acknowledging each request to guarantee that
the data was permanent. We don't do that. So the first apache process
writes the first part of the transaction, gets killed, and a second
apache process takes over an writes the rest of the transaction. Only
the second process runs fsync. Some, or all, of the data written by the
first process may be missing, so if/when the transaction is finally
committed the result is not well defined.
OK. You're trying to handle a unclean shutdown.
In this case, sounds like you want to get transactional with the
transaction :)
I think you would want to throw away the transaction entirely. Could
leave a dirty file there and if a process sees with when it starts to
modify the transaction, it bails.
Blair
