DDS — DDS ISSUE# 53] Refactor lifecycle state

Ref-84 Lifecycle_state_refactor

The precise interpretation and representation of the lifecycle and
sample states in the specification is not clear.

Figure 2-11 is not easy to interpret as it refers to "observable"
lifecycles rather than representing some internal state that the
application accesses.

Several issues are left open such as

Whether what happens if in the sample history of a single instance are
new, modified, and deleted samples (i.e. the instance was disposed and
then created again before the reader accessed it). An additional
question is then whether the read/take will return samples belonging
to multiple "generations" of the instance.

How can an application determine that as a result of a single
read/take operation multiple samples of the same instance appear. This
may be important because the processing a new/modified sample may
depend on the number of samples the application has for that instance.

Also the representation of the instance_state as an enumeration:
NEW/MODIFIED/DELETED/NO_WRITERS is not natural. If this represents the
state of the instance, then the instance can be simultaneously
MODIFIED and DELETED; it can be MODIFIED and have no writers,
etc. That is logically these are not mutually exclusive

**PROPOSAL**

Change the description in section 2.1.2.5.1 and representation
lifecycle as described below.

Replace the lifecycle_state with the following two variables (flags)

observation_lifecycle =

liveness_lifecycle =

Define DISPOSED as the union (DISPOSED_EXPLICIT | DISPOSED_NO_WRITERS)

The observation_lifecycle and liveness_lifecycle are independent. All
combinations are possible. So the lifecycle may be simultaneously NEW
& DISPOSED_EXPLICIT, NOT_NEW & ALIVE, etc.

All the samples in the history of an instance have the same
"lyfecycles" states. Each time a sample is received (or a loss of
liveliness on a remote DataWriter is detected) the liveness_lifecycle
may change. If it changes it changes for all samples belonging to the
same instance.

If an instance was DISPOSED (either DISPOSED_EXPLICIT or
DISPOSED_NO_WRITERS) and a samplefor that instance is received, the
liveness_lifecycle of the instance changes to ALIVE.

If a sample is received for a DataWriter, indicating that the ser has
called "dispose" for that instance then the liveness_lifecycle of the
instance changes to DISPOSED_EXPLICIT.

If the infrastructure detects the loss of liveness of a DataWriter for
the instance and this is the only DataWriter writing the instance
known to the reader then the liveness_lifecycle of the instance
changes to DISPOSED_NO_WRITERS

Each time the liveliness of an instance changes from ALIVE to
DISPOSED_EXPLICIT an internal count maintained per instance
(disposed_explicit_count) is incremented. Each time the liveliness of
an instance changes from ALIVE to DISPOSED_NO_WRITERS an internal
count maintained per instance (disposed_no_writers_count) is
incremented.

The observation_lifecycle and liveness_lifecycle as well as the
disposed_explicit_count and disposed_no_writers_count appear in the
SampleInfo returned when the application reads/takes samples. This
counters are from the perpective of the DataReader and start at 0 when
the liveness_lifecycle is NEW

Each time the application reads or takes samples, all returned samples
for any one instance have the same observation_lifecycle and
liveness_lifecycle. They represents the "snapshot" of the
corresponding values for the instance taken at the time the data is
read or taken.

The disposed_explicit_count and disposed_no_writers_count in
SampleInfo are not the same. On all samples. They represent the number
of lifecycles of each kind that the instance had gone through at the
time the sample stored into the history queue. The application can use
this to distinguish samples belonging to different generations. In
addition the SampleInfo contains an additional filed. The
"instance_rank" that specifies how many samples for the same instance
follow in the sequence retuned as part of the read/take. This helps
the application anticipate that more samples for the same instance
follow. The last sample for the instance returned will always have a
instance_rank==0

In addition the SampleInfo contains an additional filed. The
"generation_rank" that specifies the generation to which the sample
belongs relative to the generations

The observation_lifecycle, liveness_lifecycle, disposed_explicit_count
and disposed_no_writers can be used as in the expressions used for the
purposes of making a Query.

Figure 2-11 should be updated to reflect the state-transitions
described above.

Both the read and take operations affect the
observation_lifecycle. The first time the application reads/takes
samples for an instance the observation_lifecycle will be NEW. After
the observation_lifecycle will be NOT_NEW.

Once the application reads/takes samples with the liveness_lifecycle
DISPOSED (either EXPLICIT or NO_WRITERS), the observation_lifecycle is
'reset' and if new samples are received for that instance the
observation_lifecycle will be set to NEW again.

see below