On 16.02.2011 23:15, 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.
In other words, use a proper crash-resistant transaction commit sequence, with automatic rollback as necessary. See the sqlite docs for a description of one way of doing this. :) -- Brane
