Paul McCullagh <paul.mccullagh@primebase.org> writes:
Hi Kristian,
Hi Paul, thanks for your detailed answer!
I was a bit difficult to explain, so please ask if anything is not clear.
It seems pretty clear from your explanation. I will take a look into the sources, and will let you know if I have any questions.
Without write or flush, this is a very fast operation. But the transaction is still committed and ordered, it is just not durable.
Cool. Note that when using 2-phase commit (which happens if the binlog is enabled or if multiple engines participate in the transaction), the transaction is effectively durable at the server level (TC will recover it in case of crash), though at the engine level it is not. And in fact the transaction is already potentially visible to slaves. [This got me thinking about the case where there is no 2-phase commit (no binlog, and no other participating engines). In this case the transaction is _not_ durable at the server level until after commit in the engine. So I do not like enforcing visibility in commit_ordered() in this case. But when there is no 2-phase commit, there is no benefit in commit_ordered() anyway. So I think I will have the server only use commit_ordered() for 2-phase commit, similar as to prepare(). Slightly more book-keeping for the engines, but saner sematics in the end. Anyway, this is not really PBXT specific, but your mail inspired me to think about it, so thanks!] - Kristian.