> 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? regards, david
