Branko Čibej <brane_at_e-reka.si> writes:
> On 17.02.2011 00:13, Philip Martin wrote:
>> Branko Čibej <brane_at_e-reka.si> writes:
>>
>>> 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. :)
>> Possibly. But that probably introduces an overhead that is entirely
>> pointless in most cases. This problem can only occur with mod_dav_svn
>> used through a proxy. So I was thinking that a near-zero overhead
>> solution is to have mod_dav_svn associate some sort of process ID with
>> the transaction (in something like the the activity database) and have
>> mod_dav_svn itself fail the commit if the process ID changes. The
>> problem can only occur when the process ID changes and for the majority
>> of commits that will not happen.
>
> You still need a mechanism that will (effectively) roll back a
> partially-written transaction, don't you?
I don't think so. If mod_dav_svn returns an error to the client, the
client will either attempt to abort the commit or simply give up.
Either way we can simply abandon the commit in the Subversion
filesystem. That is what happens now if the client crashes. The
repository administrator can use "svnadmin lstxns/rmtxns" to clean up
periodically if thought necessary, but abandoned transactions can simply
exist for ever.
> And I expect only FSFS has this problem, whilst BDB does not?
Not sure, it may depend on the bdb-txn-nosync setting.
--
Philip
Received on 2011-02-17 00:31:03 CET