Determine if correlation id required when dealing with SpanData

[objectiser]

As per comment #3 (comment).

[objectiser]

The SpanData provided with the callbacks on the Observer API are intended to provide information for use by that callback to either directly perform a task at that point (stateless) or accumulate/aggregate details (stateful) for use at a later stage.

If using the stateful approach, then the subsequent callback methods need to be able to correlate the Span associated with the supplied data with information previously cached for the same Span.

Therefore we need some way to uniquely identify the Span associated with the SpanData (i.e. index into a map of information being accumulated about the span).

The current approach provides an 'id' value using the getCorrelationId method on the SpanData. Another proposal is to just use the Java object identity (e.g. hashCode/equals) of the SpanData instance to determine a unique identity for use in a map.

I think my preference is for the current (correlation id) approach, as the callbacks should not retain a reference to the SpanData, but just view it as a snapshot of the current state of the span, and copy out any relevant details for its own purpose. Otherwise it may get complicated, if later callbacks tried to access the information in a previously stored SpanData instance - should they see the snapshot from before or a view on to the current state of the span(?) - that would need to be defined.

[objectiser]

opentracing/specification#24 (comment) If there was a SpanId - then it could be used instead of a Correlation ID - however my understanding from previous discussions is that this would imply all tracer implementations used the same concept of Span. So Correlation ID is a localised workaround - it doesn't imply any global identity, just a way to link callbacks as being related to the same span.