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