Invocation sequence sensor specification

The sequence tracer provides a means to connect concrete tracer invocations within a user transaction. It acts as a container for the invocations of all tracers within the user transaction and collects the concrete values of their execution. Thus the information gathered by the sequence tracer, allows to present the sequence of all executed tracers for one user transaction. Depending on the tracers executed, this will give information about the execution time of methods (time sensor) or information about when an object is created during the user transaction. Instrumenting a method with the sequence tracer defines the starting point of a trace. All following sensors that are called, must write the result of the invocation to the sequence tracer temporal storage. No additional sequence tracer has to be defined for the sensor to be included with the sequence.

The sequence tracer currently does not allow nested sequences. Thus a subsequent sequence tracerdefinition will be ignored by the code. The integration of nested sequences would neccesitate that nested and parent sequence must refer to each other.

Invocation sequence data

Each sequence trace must provide:

• Logical name of the [xxx]
• method on which the tracer was defined
• All sensors being called together with:
  • timestamp the sensor was called
  • result of the sensor invocation

On the CMR the domain model describes method-based and non-method-based sensor types. The difference is, that method-based sensor types provide a MethodIdent during the registration whereas non-method-based sensortypes don't. The sequence tracer is defined for a method (starting point of the sequence) and thus will be a method-based sensor type. The logical name issued by the user during within the configuration will be registered with the MethodIdent.

Invocation sequence concept

All existing method sensor types which are implemented do not have to be changed in order to work within the record context of a single invocation sequence. Its transparent because the invocation sequence tracer sensor provides all methods of the core service to store and receive the current data objects. So when the Timer sensor type for example tries to access and write its own data object, it will be placed in the current invocation sequence.

After the invocation sequence tracer receives the afterMethodHook the data of the thread-local value object is taken and forwarded to the sending component.

The HookDispatcher class is modified, too, as the core service used by the different sensor types needs to be switched if a record of an invocation sequence is started. Only one invocation sequence can be recorded per thread, so if an invocation sequence should be started, but one is already running, it will just be discarded.