[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Restarting Apache during a commit through a proxy

From: Branko ─îibej <brane_at_e-reka.si>
Date: Wed, 16 Feb 2011 23:53:06 +0100

On 16.02.2011 23:15, Philip Martin wrote:
> Blair Zajac <blair_at_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
Received on 2011-02-16 23:53:49 CET

This is an archived mail posted to the Subversion Dev mailing list.