On 02/16/2011 02:15 PM, 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.
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
Received on 2011-02-16 23:57:32 CET