You may receive various outer transaction-related errors if you
attempt to overlap running graphs wrapped in an outer transaction with graphs
that do not start an outer transaction.
In general, only one outer transaction can be
open and running at a time.
The following examples illustrate a few possible scenarios in which
transaction-related errors may occur:
- Suppose you have two
projects, one without an outer transaction (A), and one with it (B). Project A
runs successfully until project B starts (and opens an outer transaction). If
project A is half-way through its run and project B starts, the remaining steps
in the project A will begin to fail because their components do not reference
the outer transaction ID.
- Suppose you have two
projects containing
Transaction RunGraph connectors. They will run
successfully if you run them serially, but any attempt to run them in parallel
will result in the second project failing.
- Suppose you have a
Transaction RunGraph set to
Do Nothing as its failure action. If this
graph fails the first time, it will also fail the second time you try to run
it, because it is trying to open an outer transaction that has already been
started. Therefore, if such a graph fails, to troubleshoot it, run the inner
graphs separately, without running the
Transaction RunGraph. Alternatively, you can
manually commit the transaction after each failure, using the
RollBack Transaction graph, specifying the ID
of the transaction. Note that the ID defaults to the
transaction string when run with a
Transaction RunGraph.
Consider implementing one of the following recommendations (depending
on your use case):
- Identify whether an outer
transaction is currently running by issuing a
listOuterTransaction request with the Transaction
Web Service.
- Before running a graph
that is configured to open its own outer transaction, verify that an already
running outer transaction commits successfully.
- In some instances, when an
already running transaction fails to commit, you may need to manually commit it
by rolling it back. Once one outer transaction is closed, you can start a new
transaction, if needed.
- Instead of running a new
graph that starts an outer transaction separately, add a component that was
previously part of this graph to any existing graph that starts an outer
transaction.
For example, you can run a graph for importing or exporting
configuration and schema inside a
Transaction RunGraph, or any other sample
graph for running a baseline update (for subsequent data loading). Similarly,
It is recommended that you run the
Reset Data Store connector inside a graph
that starts an outer transaction.
To summarize, to avoid transaction-related errors, ensure that
projects containing transactions do not overlap. Errors are avoided if at any
given time, only one outer transaction is open.
