ExecutionPlan Variables

Variables

While in the process of executing an ExecutionPlan, the two main actors, are the elements that represent an execution step, either by controlling the flow of execution or by invoking some processing actor, and the second is the data that are provided to the actors as well as the results produced by these actors. This data is usually also the target of the execution. The data is stored as typed structures using the engine available Data Types.

Wherever a plan element needs to define some association with some data stored in such a Data Type it references it using a unique name. Data Types are generally encapsulated as Named Data Types. This encapsulation provides some additional metadata on the Data Type. This metadata include a unique name by which the data are referenced. Additionally a grouping tag can be applied to a data type which can be used by some Filters that operate on this data. Finally, a flag indicating that the data is available for usage is also included so that while in execution, no element will try to use some data that is not yet available.

Named Data Types are considered as the Variables of a running execution plan. One of the ExecutionPlan's root elements is a collection of Variables. These provide a global placeholder for all Plan Elements to retrieve data from as well as to store data so that they are later on used by either a different Plan Element or to be returned to the client. Access to this global collection is moderately supervised. This means that while the underlying data structures are protected from concurrent modifications, the actual synchronization is performed mainly by the access and timeplan dictated by the ExecutionPlan's execution tree.

This for example means that if two Plan Elements share a variable, having one of the elements produce a value that is placed in the variable and the second element accessing it, the correct access to the variable is mainly enforced by the execution path that connects the two elements. If the the producing element is defined in the plan as a child of a Sequence node, and the consuming element is also a child of this element or some other element that preserves this ordering, the access will be safe. In the case though that for example the two elements are direct children of a Flow element, there is nothing ensuring that the consuming element will access the variable after the producing element. As a last line of defense, the engine provides the above mentioned flag indicating that some variable is initialized and populated. This way some cases of mis-usage can be avoided and the execution stopped before corrupt data are used.

Parameters

Access to Variables and their underlying Data Types is never performed directly from the Plan Elements. Access is always performed through Parameters. Parameters are distinguished based on their direction and the processing they are performing on the Variable and underlying Data Type before storing or accessing the actual data.

Based on the direction, Parameters can be separated to:

• In parameter

  Data can be retrieved using this parameter

• Out parameter

  Data can be stored using this parameter

• InOut parameter

  Data can be retrieved and stored using this parameter

Based on the processing, Parameters can be separated to:

• Simple

  Direct access to the underlying data is enabled

• Filter

  Before retrieving, or storing, the parameter will apply a number of Filters

Filter parameters contain an ordered list of Filters. Every time such a parameter is requested to retrieve or store some data, it goes through the list of filters. After all the filtering steps are completed, the value is retrieved or stored depending on the parameter direction. At every intermediate filtering step intermediate data are produced which depending on the definition of the filter may also be stored.