[Standards-JIG] An XMPP Race Condition most Vexing
chris.mullins at coversant.net
Sat Oct 28 00:03:43 UTC 2006
> AFAIK nobody ever proposed, that on the interface of
> a bank (e.g. the online banking web-site) the user
> first has to get alock on his own bank account and
> the the destination's bank account, then transfer
> the money, and afterwards releasing the locks again.
That's not really the use case here.
Think of the B2B case where Bank of America is performing a transfer to Wells Fargo - all over an electronic link using standard protocols.
They're going to use a protocol that has Transactions - this means (today) using a Web Service implementation that has support for WS-Transaction. If they can get this "for free" from an out-of-the-box protocol, they're going to use it. This applies to BizTalk (or any B2B) communications running over Web Services, pretty much all upcoming SOA Services that need transactions, and other related cases.
In the XMPP world, we already see this sometimes:
- Two users exchange presence subscriptions over an s2s link.
- during that exchange, server2 goes down, but server 1 has already sent the message.
- Server 1 will never resend the message. Server 2 will never process the message.
- How often do we see goofed up Roster Items as a result of this? Pretty often, if my jabber.org roster is any indication.
If we did this presence subscription in the context of a Transaction, the entire problem would disappear. We would have a transaction timeout, and the changes would get rolled back.
More information about the Standards