[Standards-JIG] An XMPP Race Condition most Vexing

[Matthias Wimmer]

Hi Justin!

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
implementations.

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".



Tot kijk
    Matthias

-- 
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/