[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Simultanaeity and the semantics of setting subscription properties
As far as I can tell, and correct me if I'm wrong, the main reason to
allow a subscription to be modified, as opposed to closing it out and
creating a new one, is atomicity. The clearest example of this I can
see is useNotify (though I'm at a loss for a use case). If I change
useNotify, then I know that I will receive every message produced
exactly once, and at some unspecified time in the future the consumer
will start seeing messages in the other format. On the other hand, if
I first create a new subscription and then delete the old, the consumer
may get some set of messages twice, once in the old format and once in
the new. We need to be careful about simultaneity here. About the only things we can count are that a message arrives after it is sent, and that for a given connection, messages arrive in the order they are sent. But if two different sources send to the same sink, the exact interleaving of arrivals is undefined. In this context I am further assuming that if the NotificationProducer receives (Subscribe new, Cancel old), any notifications produced between these events will go to both subscribers. But this is not certain, and we need to nail this down. Now let's consider the various properties that can be set:
If so, how important are the atomicity guarantees for setting properties? The worst side effect seems to be the possibility of duplicate messages. And if guaranteeing ordering of subscriptions/cancellations is not feasible, how feasible are the atomicity guarantees for setting properties? My gut feeling right now is that significantly changing a subscription's properties in-flight is tantamount to canceling it and creating a new one, and it would be nice to reflect that without losing useful atomicity properties. In any case, the key semantic to look at is the ordering of events in an inherently loosely-ordered system. Hope that makes sense. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]