You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Hyrum K Wright <hy...@hyrumwright.org> on 2011/04/22 23:11:27 UTC
Cancellation and wc-ng txns
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.
-Hyrum
Re: Cancellation and wc-ng txns
Posted by Branko Čibej <br...@e-reka.si>.
On 22.04.2011 23:34, Hyrum K Wright wrote:
> 2011/4/22 Branko Čibej <br...@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
Re: Cancellation and wc-ng txns
Posted by Hyrum K Wright <hy...@hyrumwright.org>.
2011/4/22 Branko Čibej <br...@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).
-Hyrum
Re: Cancellation and wc-ng txns
Posted by Branko Čibej <br...@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.
-- Brane