[Standards-JIG] An XMPP Race Condition most Vexing
justin-keyword-jabber.093179 at affinix.com
Thu Oct 26 00:40:09 UTC 2006
On Wednesday 25 October 2006 4:07 pm, Robert B Quattlebaum, Jr. wrote:
> I think the easiest way to solve this is to store the subscription
> state in two columns instead of one. If you think about it, the
> subscription state is most naturally expressed as two individual bits
> of information. Just have a boolean 'sub-to' column and a boolean
> 'sub-from' column in your database, and then you don't have to worry
> about a change to one clobbering the other. Some jabber
> implementations already do this.
> I agree with Matthais that this is not a protocol-level issue, but
> instead an implementation-specific issue.
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
Obviously, given the protocol that we have today, his problems are
implementation-specific. If the protocol limits your ability to be
concurrent, then you must limit your concurrency. That's just the way it is.
However, his basic concern is still valid.
The questions are:
1) Can a higher concurrency implementation be made with the existing
protocol? Chris says no, but what do others say?
2) If the answer to #1 is no, then what steps would have to be taken
protocol-wise to allow it?
More information about the Standards