[Standards-JIG] An XMPP Race Condition most Vexing
m at tthias.eu
Fri Oct 27 23:52:39 UTC 2006
Justin Karneges schrieb:
> I talked with Chris about this off-list, since there was some confusion in his
> explanation. Essentially, the problem is that the XMPP subscription protocol
> doesn't easily allow for concurrency (threads, etc). As it stands, certain
> operations have to be serialized. What he is suggesting is a protocol or
> guideline to allow for higher concurrency without having to serialize all
> these operations.
I something has to be serialized, you should always keep the part, that
has to be serialized, as small as possible. Getting a "lock" or
something like that over the network is unnecessarily heavy-weighted
while it can be done locally - or might not even be necessary on some
The typical example everybody knows for locks being a requirement on
some transactions is a bank account and two concurrent money transfers
on this account.
I think everybody agrees, that acquiring the necessary locks is
something the thread executing a money transfer at the bank has to
manage on its own. AFAIK nobody ever proposed, that on the interface of
a bank (e.g. the online banking web-site) the user first has to get a
lock on his own bank account and the the destination's bank account,
then transfer the money, and afterwards releasing the locks again.
> The questions are:
> 1) Can a higher concurrency implementation be made with the existing
> protocol? Chris says no, but what do others say?
I say "yes".
Matthias Wimmer Fon +49-700 77 00 77 70
Züricher Str. 243 Fax +49-89 95 89 91 56
81476 München http://ma.tthias.eu/
More information about the Standards