Thanks for taking a look...
I don't think it's too long for a blog post, but if you do then why not break it up into a series?
I'm kind of using this as a way of preparing the content for my JUDCon talk, so it will get longer when I add the code examples. I've split it into 4 parts now, so this should solve the problem.
ACID does not require locks. You can use timestamps, for instance. It's also wrong to say that locking "achieves" ACID transactions, since locks (or some form of concurrency control) is only applicable to the I in ACID.
You mention the blocking nature of transactions, but don't say why it exists. It's not to do with locking, but that is the inference.
Unfortunately whilst the strict 2PC protocol guarantees atomicity, no transaction manager actually implement that otherwise we'd have transactions that don't (can't) complete. Hence heuristics.
Agreed, I'll update the text.
In general I think there are too many generalities in the text so far, such as "In a compensation-based transaction, changes are visible outside of the transaction as soon as they are made." That's only true for certain compensation transaction models, not all. And they don't guarantee an atomic outcome any more than ACID transaction managers do.
I agree. I think this has come as a side-effect of me trying to reduce the amount of text (I'm concerned that people won't read it if it's too long; but clearly accuracy is paramount). Hopefully turning this into a four-part series will give me the space to explain things more accurately.