David Nuescheler wrote:
When you commit the transaction, the transaction manager will call
commit on both sA and sB. If sA fails to commit (and it will not fail
until sA and sB are in prepared state because prepare() is a
no-op at the moment) it is impossible to rollback the transaction as
sA AND sB are both instructed to commit by the transaction manager.
I hope you see my point now. For me, ACIDity seems very highly
endangered.
i think we all agree that the current in implementation
with the no-op in the prepare is "suboptimal" to put it
in a nicely.
if that's your concern (which i assume everybody shares),
my question is why didn't you just put that is response
to dominique's answer, in that other thread?
i think we would all have agreed, case closed.
what was confusing me was that i have no idea
what this has to do with locking or the spec then?
What was confusing me was your statement that, to quote:
"... of course locking can easily be part of a global transaction."
Now you agree that this is not the case.
It was by no means my intention to waste your time, so please
accept my apology. I was just reasoning about how transactions
should be used in jackrabbit. A big thanks to Dominique for
the transaction stuff as it is really hard to tackle it down.
To quote you once again: "... case closd." ;-)
Regards,
Felix
regards,
david
