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
