On 26.09.2012 02:08, Tim Starling wrote:
I think that to avoid confusion, begin() and commit() should continue to issue the queries they are named for.
True. So we'd need start() and finish() or some such.
Your scheme does not appear to provide a method for hooks to release highly contended locks that they may acquire. Lock contention is usually the most important reason for calling commit(). Holding a contended lock for an excessive amount of time has often brought the site down. Imagine if someone wrapped a hook that writes to site_stats with begin/end. The code would work just fine in testing, and then instantly bring the site down when it was deployed.
I see your point. But if we have the choice between lock contention and silent data loss, which is better? While I agree that inconsistencies in secondary data like link tables is acceptable, I think we do need a way to protect critical transactions to prevent data loss.
Hm... if we use flush() for immediate commits, and start() and finish() for blocks that disable immediate commits (i.e. critical transactions), then a "silenced" flush() inside an start() and finish() block should issue a warning. That would make tests fail. Would you be OK with that?
So, my current proposal is a more expressive high-level api for transaction control consisting of start/finish/flush (and perhaps abort) on top of the low level interface consisting of begin/commit/rollback. Documentation needs to be very clear on how they behave and how they relate to each other.
For the short term, I suggest to suppress warnings about nested transactions under some conditions, see my previous response to aaron.
-- daniel