In ADF transactions are defined and owned by the underlying business service implementation used
within the Model layer of the
application. As example ADF Business Components take out connections and
transactions with the database. Such services are then exposed to the View
Controller layer through an abstraction known as a Data Control for the View Controller to work with.
As our application can utilize
multiple data controls, the ADF Controller (ADFc) through the facilities
provided by the task flow transaction and data control scope options, allow one
or more data controls to be grouped together and committed or rolled back as a group.
The underlying business services
still own the transaction and ultimately execute the commit and rollback operations,
but the ADF Controller defines the
boundaries of the task flow transaction, namely where the transaction
starts and stops and which data controls are involved.
For the bounded task flow
transaction option itself there are only 4 options:
·
"<No Controller Transaction>"
·
"Always Begin New Transaction"
·
"Always Use Existing Transaction"
·
"Use Existing Transaction if Possible"
Data control scope:
·
Isolated
·
Shared (Default)
Shared Scope
When a task flow defines a shared data control scope, this implies
the task flow will attempt to share any
instance of a data control (and by implication it's state) with the task
flow's caller if the data controls have the same definition, rather than
creating a new instance.
Isolated Scope
If a task flow defines an isolated data control scope, even if
both task flows use the same design time data control definition, at runtime each
task flow will have their own instance of
the data control.
Data Control Frame
The Data Control Frame is the
magic behind how this works. Essentially each task flow has the potential to
have its own data control frame containing a list of the used data controls. A
data control frame is created at runtime
for your application's unbounded task flow and any isolated data control scoped
bounded task flow.
However when a bounded task flow
specifies a shared data control
scope the current task flow uses the
data control frame of the caller
rather than creating its own, giving the called task flow the chance to share
data control instances attached to the frame.
Alternatively if the bounded task flow
specifies an isolated data control
scope, a new frame will be created and a
new instance of any data controls used by the bounded task flow will be
attached to this new frame.
Now let’s see the different
options available in transaction management in Taskflows:
Always Begin New Transaction
It is used to start a new transaction in your
application. Typically this option is coupled with the isolated data control scope and a new separate data control frame.
If a bounded task flow does start
with a new transaction, when it wishes to
complete it must call a task flow return activity commit or rollback. These
call the underlying commit() or rollback() operations on the associated data
control frame, essentially committing or rolling back all data controls
attached to the frame.
Always Use Existing Transaction
A bounded task flow that uses the
"Always Use Existing Transaction" option is designed to share the transaction of the previous task
flow in your application; it will not start a new transaction.
On closing it cannot make use of a commit or rollback task flow return
activity, at design time such a task flow return activity will be flagged in
error. Only a task flow that starts a new transaction can call these. In this
case the "Always Use Existing Transaction" option will depend on its
caller to finalize the transaction. Instead the "Always Use Existing
Transaction" task flow simply calls a task flow return activity with its
End Transaction property set to "<Default> none".
Use Existing Transaction If
possible
It is the most flexible of the transaction options and it is a combination of
the "Always Begin New Transaction" and "Always Use Existing
Transaction" options.
If "Use Existing Transaction
if Possible" is used with an
isolated data control scope, it operates in the same manner as the "Always
Begin New Transaction" with an isolated data control scope creating a
new data control frame.
If "Use Existing Transaction
if Possible" is used with a shared
data control scope its behaviour is dependent
on if a transaction is open on the shared
data control frame of the caller.
If a transaction is open it has the same behaviour of
"Always Use Existing Transaction" with a shared data control scope.
If a transaction is not open, it behaves the same as
"Always Begin New Transaction" and a shared data controls scope.
No Controller Transaction
"<No Controller
Transaction>" option is restricted in its interaction with the data
control frame; it does have a more liberal relationship with its relating data
controls and their transactions.
·
Doesn't start a transaction on the data control frame like
the "Always Begin New Transaction" option
·
Doesn't check or enforce if a
transaction is
open on the data control frame
·
Will not call finalize the data
control frame transaction by calling the
Data Control Frame commit() or rollback().
The established rules still apply for the data control scope
though. If an isolated data control scope is specified for the task flow a new
data control frame and data controls will be instantiated. For a shared data
control scope the previous task flow's data control frame and data controls
will be shared.
