I don't think this is quite ready to go into spec-ese, but here's a
summary:
When some property of a subscription is changed, two points in time are
of interest:
- t1, the latest point before which all messages are produced with
the old property
- t2, the earliest point after which all messages are produced with
the new property
In general, we can make no guarantees about t1 and t2, not even that t1
< t2.
Here are some possible scenarios:
- In the case where the Subscriber makes a new subscription with
the new property, waits for the SubscribeResponse and then cancels the
old subscription:
- In the fully distributed case, there is no guarantee at all
about t1 and t2
- In cases we can serialize creation and destruction of
subscriptions along with the mapping of events to notifications
produced (and there are a couple of tricky points to this), we can
guarantee that t1 < t2. In the interim between t1 and t2,
notifications may be produced for both subscriptions. Productions for
the same event may occur in either order, but we may be able to
guarantee that, say, if e1 occurs before e2, then all notifications for
e1 will be produced before any for e2. This seems like a separate
policy from subscription continuity.
- In the case where there is a single subscription whose property
is changed
- The default is unconstrained, equivalent to the fully
distributed two-subscription case above.
- If we can guarantee t1 < t2, then the question is whether a
single event can lead to more than one notification for the
subscription.
- If so, we have the serialized two-subscription case above
- If not, we have a somewhat odd case in which, in the interim,
a given event may produce a notification according to either the old
rules or the new, but not both.
- If we can guarantee that t1 <= t2, and that no notifications
will be produced between t1 and t2, we have the "Exactly Once" or
"Atomic" case.
It's a bit discomforting to talk about the mapping from events to
notifications, but I don't see how to talk about duplicate messages
without doing something along those lines. Notifications are duplicate
exactly if they pertain to the same event. We may be able to abstract
this a bit, and refer to some externally-defined notion of duplicate
notifications.
Actually, the key question is whether any messages are produced at a
time tm, with t1 < tm < t2.
The scenarios above are generic. In terms of specific properties:
- For filter properties, we consider the intersection of the
messages that would be produced by the old and new filters. If t2 <
t1, we may lose messages. If t1 > t2, we may get duplicates of
messages in the intersection. If t1 >= t2 and nothing is produced
between t1 and t2, we have exactly once semantics on the intersection.
- For consumer reference, if t2 < t1, we may lose messages.
Otherwise, any messages produced between t1 and t2 will be produced for
both consumers.
- For the continuity policy itself, if the property change comes
before the subscription change, then the subscription will definitely
follow the new continuity rules. If the property change comes after
the subscription change, then the subscription will definitely follow
the old rules. If you can't serialize the two operations, then the
subscription might follow either rules. Them's the breaks.
- For other policies, any notifications produced between t1 and t2
may follow either policy.
These all seem essentially similar.
So in summary/rehash, an NP may make any of these guarantees about t1
and t2:
- Nothing
- t1 <= t2, in which case the NP can guarantee one of
- No messages will be produced (for the subscription in question,
at least) between t1 and t2 (this is the exactly once case)
- No duplicate messages will be produced in that interim (but
they may alternate as to which rule they follow.
- There may be duplicates, one for each version of the
properties, in which case
- There may or may not be non-duplicates interleaved between
two duplicates. If there may be, we have the same semantics as the
unconstrained two-subscription case.
The rules for specific properties above follow straightforwardly from
this, I think.
|