[Standards-JIG] An XMPP Race Condition most Vexing

[Justin Karneges]

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 
these operations.

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?

-Justin