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

Re: Cancellation and wc-ng txns

From: Branko Čibej <brane_at_e-reka.si>
Date: Fri, 22 Apr 2011 23:50:12 +0200

On 22.04.2011 23:34, Hyrum K Wright wrote:
> 2011/4/22 Branko Čibej <brane_at_e-reka.si>:
>> On 22.04.2011 23:11, Hyrum K Wright wrote:
>>> What's the relationship between cancellation functions and
>>> transactions in wc-ng?
>>> In the interests of performance and correctness, we've been moving
>>> toward a model where more and more gets done in a single wc-ng
>>> transaction. I've no problem with that, and like the atomicity and
>>> speed it gives us, but how does that interact with our cancellation
>>> functions? Do we still check for cancellation from within the
>>> transaction? If the user cancels, do we rollback the transaction, or
>>> commit it?
>>> My question then is two-fold:
>>> * what actually happens today?
>>> * and what is the Right Thing to happen?
>>> My own thoughts: we should check for cancellation, and if it occurs,
>>> we should rollback the txn.
>> If the transaction is so long-running that cancellation checks would
>> make sense ... then something's wrong, as AFAIUI long-running
>> transactions are frowned upon around here. Still, if that does happen,
>> then the only thing you can do when an operation is canceled is to roll
>> back the transaction -- anything else would be bound to produce invalid
>> state in the database.
> I would tend to agree on both points, and I also wonder if/how our
> cancellation checks and handlers become a bit obsolete with atomic
> database operations (which execute in only a few queries, rather than
> a multitude of tree walks).

Cancellation checks are for more than just WC operations, and WC
operations can take a long time even when judicious use of transactions
makes them "fast". I'll haul out the recursive proplist example again ...

-- Brane
Received on 2011-04-22 23:50:42 CEST

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.