Paul Robinson [
https://community.jboss.org/people/paul.robinson] commented on the
document
"Compensating Transactions: When ACID is too much"
To view all comments on this document, visit:
https://community.jboss.org/docs/DOC-48610#comment-11985
--------------------------------------------------
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.
--------------------------------------------------