Cost-Based Optimization of Integration Flows - Datenbanken ...

4.2 Plan Vectorization
a subplan of our example plan P 1 shown in Figure 4.6(a). The vectorized plan P 1 ′ is
the output of the A-PV and it is shown in Figure 4.6(b). There, the Switch-specific
rewriting technique has been applied, where we have created two pipeline branches (one
for each switch-path) and changed the data flow such that messages are passed through
the Switch operator. In order to avoid message outrun, we inserted the XOR operator
and the synchronization queue. Note that the full plan of P 1 required additional Copy and
And operators for the last Invoke operator because it depends directly on the output of the
Translation operator. This serialization concept will be discussed separately.
Rewriting Iteration operators. When rewriting Iteration operators, the main problem
is also the message outrun. We must ensure that all iteration loops (for a message)
have been processed before the next message enters. Basically, a foreach Iteration is
rewritten to a sequence of (1) one Split operator, (2) operators of the Iteration body
and (3) one Setoperation (UNION ALL) operator. Using this strategy, inherently leads to
the highest degree of parallelism, while it requires only moderate additional costs for splitting
and merging. In contrast to this, iterations with while semantics are not vectorized
(one single execution bucket) because we cannot guarantee semantic correctness.
Rewriting Savepoint operators. Within the instance-based model, we can use messagespecific
and context-specific savepoints. Due to the missing global context, we need to
reduce the savepoint semantics to the storage of messages, where context information needs
to be stored via specific messages. However, in order to ensure the semantic correctness,
we require two different rewriting methodologies. The message-specific savepoint is simply
vectorized in a standard manner. In contrast to this, the context-specific savepoint, that
stores all current messages at a certain plan position, must be rewritten in a more complex
way. Here, we need to insert one savepoint into each parallel data flow branch with respect
to the operator position in the instance-based case.
Rewriting Invoke operators. In order to realize the serialization of external behavior
(precondition for transparency), we must ensure that explicitly modeled sequences of writing
interactions (Invoke operators) are serialized (see Rule 3 of Definition 3.1). Hence,
we use the And operator for synchronization purposes. If (1) two Invoke operators have
a temporal dependency within P , (2) they perform a writing interaction to the same external
system, and (3) they are included in different pipelines in P ′ , we insert an And
operator right before the second Invoke operator as well as a synchronization queue between
the first Invoke operator and the And operator. The And operator reads from the
synchronization queue and from the original queue and synchronizes the external behavior
by deferring all messages until its source message ID is available in the synchronization
queue. We use an example to illustrate this concept.
Example 4.4 (Serialization of External Behavior). Assume a dependency graph DG(P 8 )
of a subplan of our example plan P 8 (see Figure 4.7(a)) to be part of a data-driven integration
flow. If we vectorize this subplan to P 8 ′ (see Figure 4.7(b)) with two pipeline branches,
we need to ensure the serialized external behavior. We inserted an And operator, where the
first Invoke sends synchronizing source message IDs to this operator using the introduced
synchronization queue. Only in the case that the Assign as well as the first Invoke have
been processed successfully, the payload message of the right pipeline branch is forwarded
to the second Invoke.
In summary, when rewriting instance-based plans to vectorized plans, we guarantee
semantic correctness for context-specific operators as well.
97