Oracle ADF Architecture TV - Design - Task Flow Transaction Options

Task Flow Transaction Options
ORACLE
PRODUCT
LOGO
Real World ADF Design & Architecture Principles
15th Feb 2013 v1.0

Learning Objectives
•  At the end of this module you should be able to:
–  Understand the Data Control Frame and how it
relates to the task flow transaction
–  What the task flow transaction options are and
how they behave
–  How the options relate to the data control scope
–  Which transaction options to combine and not
–  How to finalize a task flow using transactions
–  What happens to a prematurely terminated
transaction
Image: imagerymajestic/ FreeDigitalPhotos.net

Prerequisites
•  Essential you've viewed and
understood the sister PPT first:
Task Flows Data Control Scope
Options
and understand the concept of the
data control frame

Program Agenda
•  Data Control Frame
•  Task Flow Transaction Options
•  Task Flow Transaction Error Conditions
•  Task Flow Transaction Finalization
•  Example Transaction Scenarios
•  Prematurely Terminated Task Flows
•  Final Note

Data Control Frame
•  Internal runtime ADF object
•  Groups task flows and their data controls at runtime
•  Defines the boundaries of the ADF controller/task flow transactions
–  If UTF = task flow has its own data control frame
–  If BTF + data control scope = “isolated” task flow has its own data
control frame
–  If BTF + data control scope = “shared” task flow uses data control
frame of previous task flow

7 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.7 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.
Data Control Frame #3Data Control Frame #2
Data Control Frame #1
UTF1
Shared
BTF1
Shared
BTF2
Shared
BTF3
Isolated
BTF4
Shared
BTF5
Isolated
BTF6
Shared
BTF7

UTF1

Data Control Frame - Edge Use Cases
•  What about separate browser tabs/windows?
–  They share the same HTTP session
–  But ADF will treat each tab via _afrWindow separately
–  Results in a brand new data control frame
–  Therefore you cannot share data controls
•  What about accessing a BTF directly by a URL in a new window?
–  Again this will result in a new data control frame
–  Therefore you cannot share data controls

Program Agenda
•  Final Note

Task Flow Transaction Options
<?xml version="1.0" encoding="ISO-8859-1" ?>
<adfc-config xmlns="http://xmlns.oracle.com/adf/controller"
version="1.2">
<task-flow-definition id="task-flow-definition">
<transaction>
<new-transaction/>
</transaction>
<data-control-scope>
<isolated/>
</data-control-scope>
<use-page-fragments/>
</task-flow-definition>
</adfc-config>

Task Flow Transactions Design
•  Task Flow Transactions
–  Are an abstraction of the transaction concept at the ADFc layer
–  Flagged by a transaction token on data control frame
•  What they were designed to do:
–  A JTA *like* ability to commit heterogeneous set of services
•  As disparate Data Control types & instances can attach to the data control frame
•  By design it allows you to commit/rollback these as a group
•  Based on BTF boundaries & calls, transaction options and TF return activities
•  Incidentally they allow multiple ADF BC root AMs to share DB connections
–  This is critical to scalable applications based on separated architectures
–  More on this later

Transaction Options Names
•  New Names
–  Always Begin New Transaction
–  Always Use Existing Transaction
–  Use Existing Transaction if Possible
–  <No Controller Transaction>
•  Old Names
–  <new-transaction>
–  <requires-existing-transaction>
–  <requires-transaction>
–  No tag
•  The transaction names have changed over JDeveloper releases
•  Some of the names were confusing so the names were changed
•  The old names are still reflected in
–  Task flow XML file
–  Out of date documentation

Always Begin New Transaction
•  Starts a new transaction on the data control frame
•  In a chain of BTF use this to start your transaction boundary
•  Supports both isolated and
shared data control scope
–  As you typically use this option to
start a new transaction, isolated
makes the most logical sense (and
is the easiest to understand)
•  Is responsible for finalizing the
transaction (more soon)

Always Use Existing Transaction
•  Joins an existing data control frame transaction
•  Use this in a chain of BTFs where you need the current task flow to join the
transaction of the previous BTF, rather than opening a new one or
controlling or finalizing the transaction
•  Only supports the shared
data control scope option
(isolated is disabled)
•  Cannot finalize the
transaction (more soon)

Use Existing Transaction if Possible
•  Supports isolated and shared Data Control Scope
•  The transaction behavior is dynamic:
–  If an isolated data control scope is set
• Becomes the Always Begin New Transaction behavior at runtime
–  If a shared data control scope is set
+ If an open data control frame transaction is detected at runtime
Becomes the Always Use Existing Transaction behavior at runtime
+ Else there is no open data control frame transaction at runtime:
Becomes the Always Begin New Transaction behavior at runtime

If you're designing a task flow for
future reuse, implying you don't
know how it will be used, the
Use Existing Transaction if
Possible + shared data control
scope is the most promiscuous
(flexible) option to select
Image: Ambro / FreeDigitalPhotos.net

<No Controller Transaction>
•  The chaste task flow transaction option
•  Would be better named <No Controller "Managed" Transaction>
•  Using this option discards the managed transactions at the controller level
–  Thus the option name, "the controller isn't controlling the transaction"
–  Similar to how applications were built in JDev 10g
–  Arguably isn't a task flow transaction option, simply turns it off
•  It can be used in combination with the other task flow transaction options
•  But it is perpendicular to their design and capabilities

If your application only uses one data
control, the <No Controller
Transaction> option is a simple
choice because you don't need to
commit or rollback a group of data
controls, you only have 1!

<No Controller Transaction> Continued
•  Supports isolated and shared data control scope
•  But doesn’t care about the data control frame or the transaction token
–  On start doesn’t create a task flow transaction on the frame
–  Does not enforce a transaction must be open on the frame
–  Will not finalize the frame with task flow return activities

21 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.21 Copyright © 2013, Oracle and/or its affiliates. All rights reserved. Image: Ambro / FreeDigitalPhotos.net
The <No Controller Transaction>
option doesn’t mean the task flow
cannot participate in a database
transaction ... it's just not participating
in an ADFc "managed" transaction

So task flows dictate if they join an ongoing task flow
transaction. Yet they have no knowledge of their caller
who may or may not have created a task flow transaction.
Hmm, that must make designing task flows for reuse
difficult? If we're building a task flow to be reused by other
task flows that have yet to be built, how do we know if a
transaction is available at runtime? Obviously we don't.....
So what transaction and data control scope options should
we use to make the task flows as flexible as possible?
Exercise

We need to call a task flow "method
call" in its own transaction. Can we
solve this with task flows?
Exercise

Program Agenda
•  Final Note

Always Begin New Transaction – Errors
•  On opening will enforce that it must be the task flow to start any ADFc
transaction on the data control frame
–  If violated throws "ADFC-00020 <task flow name> requires a new transaction,
but a transaction is already open on the frame"
•  Opening will always succeed if it uses:
–  Isolated data control scope - why?
•  As this starts a new data control frame, there will never be a preexisting ADFc transaction
–  Shared data control scope & the previous TF is a UTF – why?
•  Where a UTF does have a data control frame, it does not set ADFc transaction options
–  Shared data control scope & the previous BTF is using <No Controller Transaction> - why?
•  Similar to the UTF, the previous BTF cannot start an ADFc transaction
•  But will throw ADFC-00020 if using shared data control scope and the
previous BTF is using any other transaction option
–  In other words the previous BTF has a live ADFc transaction on the frame

Always Use Existing Transaction - Errors
•  On opening will enforce that there must be a preexisting data control
frame transaction
–  This explains the shared only data control scope option
–  If violated throws "ADFC-00006: Existing transaction is required
when calling task flow <task flow name>"
–  Requires that somewhere prior to the existing BTF in the current data control
frame an Always Begin New Transaction BTF was used
•  Not necessarily the direct caller as this could have also been an Always Use
Existing Transaction or Use Existing Transaction if Possible BTF which
themselves are dependent on a caller carrying a token on the frame

Use Existing Transaction if Possible - Errors
•  As behavior of this tag is dynamic and defaults to the other options
•  The error conditions it throws depends on which option it chooses

<No Controller Transaction> - Errors
•  The <No Controller Transaction> doesn't participate in the controller
transaction or data control frame concept
•  Therefore it doesn't throw any relating ADFc errors

Program Agenda
•  Final Note

Task Flow Transaction Finalization
•  To commit/rollback all data control instances attached to the data
control frame (aka. task flow transaction) you must:
–  Use a task flow return activity with the End Transaction property either set
to commit or rollback
–  Or programatically commit or rollback the data control frame
BindingContext ctx = oracle.adf.controller.binding.BindingUtils.getBindingContext();
String frameName = ctx.getCurrentDataControlFrame();
DataControlFrame frame = ctx.findDataControlFrame(frameName);
frame.commit(); // or frame.rollback();

Hmm, what happens if we're using
task flows with the transaction
options, yet we use a commit or
rollback operation from the Data
Control Palette instead of a task flow
return activity?
Exercise

Task Flow Transaction Finalization
•  Contrary to the task flow return activities using commit/rollback
•  If you use the Data Control Palette commit or rollback operations
–  You will bypass the task flow transaction management
–  You must commit/rollback every single data control yourself
•  This wont matter if you have only one data control type or instance
•  Yet totally breaks the whole point of using task flow transactions
•  Note JDeveloper does not warn you if you make this mistake

Task Flow Return Commit and Rollback
•  All task flows can use task flow return activities with commit and rollback
–  Design time warnings will show when they're mandatory or you shouldn't use them
–  But at compile time and runtime the wrong options will just be ignored
•  Only the task flow that starts the data control frame can actually commit or
rollback the complete transaction, therefore that's BTFs that use:
–  Always Begin New Transaction
–  Use Existing Transaction if Possible defaulting to Always Begin New Transaction
•  For the following task flows participating in a data control frame transaction
the task flow return commit or rollback will be ignored
–  Always Use Existing Transaction
–  Use Existing Transaction if Possible defaulting to Always Use Existing Transaction
•  But you can use task flow return activities with Restore Save Point option

So the behavior of a Use Existing
Transaction if Possible task flow is
dynamic at runtime.
How should we configure the task flow
return activities if we don't know if the
task flow will initiate the transaction?
Exercise

Program Agenda
•  Final Note

Scenario – Completely Separate Transactions
•  We want one BTF to call another BTF
•  But have completely separate transactions
•  Why? Can you think of a scenario that would need this?
•  How would you design this?:
–  Start with Unbounded Task Flow
–  Calls a Bounded Task Flow #1
•  Data Control Scope?:
•  Transaction Option?:
•  Data Control Scope?:
•  Transaction Option?:
Isolated
Isolated

Data
Control
Frame
#0
Data
Control
Frame
#1
Data
Control
Frame
#2

Unbounded
Task
Flow
Bounded
Task
Flow
#1

Isolated
Data
Control
Scope

Always
Begin
New
TransacCon

Bounded
Task
Flow
#2

Isolated
Data
Control
Scope

Always
Begin
New
TransacCon

Task
Flow
Transac-on
A

Task
Flow
Transac-on
B

Transac-on

Dirty

Update
X
=
30

X
=
10

Y
=
20

X
=
30

Y
=
20

X
=
10

Y
=
20

Transac-on

Dirty

Update
Y
=
40

X
=
10

Y
=
40

Task
Flow
Return

Commit

X
=
30

Y
=
20

Task
Flow
Return

Commit

X
=
30

Y
=
40

Scenario

UTF
calls
BTF#1

BTF#1

Isolated
Data
Control
Scope

Always
Begin
New
Transac-on

BTF
#1
calls
BTF#2

BTF#2

Isolated
Data
Control
Scope

Always
Begin
New
Transac-on

Call

Call

Y
=
40
X
=
30

Scenario – Guarantee Joined Transactions
•  We want one BTF to call another BTF
•  And we want the 2nd BTF to borrow/join transaction of the first
•  Why? Can you think of a scenario that would need this?
•  How would you design this?:
–  Unbounded Task Flow
•  Data Control Scope:
•  Transaction Option:
•  Calls a Bounded Task Flow #2
•  Data Control Scope:
•  Transaction Option:
Isolated
Shared
Always Use Existing Transaction

Data
Control
Frame
#0
Data
Control
Frame
#1

Unbounded
Task
Flow
Bounded
Task
Flow
#1

Isolated
Data
Control
Scope

Always
Begin
New
TransacCon

Task
Flow
Transac-on
A

Scenario

UTF
calls
BTF#1

BTF#1

Isolated
Data
Control
Scope

Always
Begin
New
Transac-on

BTF
#1
calls
BTF#2

BTF#2

Shared
Data
Control
Scope

Always
Use
Exis-ng

Transac-on

Call

Data
Control
Frame
#1

Bounded
Task
Flow
#2

Shared
Data
Control
Scope

Always
Use
ExisCng
TransacCon

Transac-on
Dirty

X
=
10

Y
=
20

Update
X
=
30

X
=
30

Y
=
20

Call

X
=
30

Y
=
20

Update
Y
=
40

X
=
30

Y
=
40

Task
Flow
Return

Commit

X
=
30

Y
=
40

Task
Flow
Return

Commit

X
=
30

Y
=
40

X
=
30

Y
=
40

Scenario – No Controller Transaction
•  For completeness let’s investigate mixing <No Controller
Transaction> and the other ADFc transaction options
•  Design:
–  Unbounded Task Flow
•  Data Control Scope: Isolated
•  Transaction Option: <No Controller Transaction>
•  Data Control Scope: Shared
•  Transaction Option: Use Existing Transaction if Possible

Data
Control
Frame
#0
Data
Control
Frame
#1

Unbounded
Task
Flow
Bounded
Task
Flow
#1

Isolated
Data
Control
Scope

<No
Controller
TransacCon>

Bounded
Task
Flow
#2

Shared
Data
Control
Scope

Use
ExisCng
TransacCon
if

Possible

Task
Flow
Transac-on
A

X
=
30

Y
=
40

Scenario

UTF
calls
BTF#1

BTF#1

Isolated
Data
Control
Scope

<No
Controller
Transac-on>

BTF
#1
calls
BTF#2

BTF#2

Shared
Data
Control
Scope

Use
Exis-ng
Transac-on
if

Possible

Call

X
=
10

Y
=
20

Update
X
=
30

X
=
30

Y
=
20

X
=
30

Y
=
20

X
=
30

Y
=
40

Task
Flow
Return

Commit

Call

Transac-on

Dirty

Update
Y
=
40

X
=
30

Y
=
40

Task
Flow
Return

Commit

X
=
30

Y
=
40

I already mentioned this...
The <No Controller Transaction> option isn't
designed to work with the other task flow
transaction options, they're perpendicular
features.
This is not to say it wont run, but it wont
necessarily work as you expected and can be
confusing.
My recommendation, don't mix the 3 other
options in a chained set of BTFs with <No
Controller Transaction>.

Exercise
Consider this scenario.
Which VO fails and why?

Exercise
Consider this scenario.
Why doesn't it fail?

Program Agenda
•  Final Note

Prematurely Terminated Task Flows
•  Task flow can be “Prematurely Terminated”
•  Premature termination occurs when a task flow is terminated before it
naturally finalizes.
•  e.g.
–  Where a parent task flow causes a child task flow to shutdown or refresh before
the child task flow has naturally finalized
–  Or the user clicks the browser back button and the child can't finalize

Prematurely Terminated Task Flow Example
<TaskFlowBean> <taskFlowInit> Task flow /WEB-INF/departments-task-flow.xml#dept-task-flow initialized
<AppModuleImpl> <create> AppModuleImpl created as ROOT AM
<AppModuleImpl> <prepareSession> AppModuleImpl prepareSession() called as ROOT AM

<TaskFlowBean> <taskFlowInit> Task flow /WEB-INF/employees-task-flow.xml#emp-task-flow initialized
<AppModuleImpl> <create> AppModuleImpl created as NESTED AM under AppModule

<TaskFlowBean> <taskFlowInit> Task flow /WEB-INF/employees-task-flow.xml#emp-task-flow finalized

Oh, I just thought of something...
If a task flow is participating in a
transaction and it is prematurely
terminated, what happens?
Do we have half a transaction still in
memory?

Prematurely Terminated Transaction Example

<TaskFlowBean> <taskFlowFinalizer> Task flow /WEB-INF/employees-task-flow.xml#emp-task-flow finalized
<AppModuleImpl> <beforeRollback> AppModuleImpl beforeRollback() called as ROOT AM
<TaskFlowBean> <taskFlowInit> Task flow /WEB-INF/employees-task-flow.xml#emp-task-flow initialize

Prematurely Terminated Task Flows
•  Why does this occur?
•  If the child TF was participating in an ADFc transaction separate to
the current TF, the framework will automatically rollback the
associated data control frame of the child
–  This is fine if the child TF is using an isolated data control scope as the rollback
will be limited to the boundaries of the child TF
–  But this can have unexpected results if a shared data control scope
–  The rollback will affect the caller too as the data controls are shared
–  As a vanilla navigation event is not typically associated with a rollback, this will
confuse the user and cause unexpected behavior

Program Agenda
•  Final Note

Final Note: EJB/JPA vs ADF BC vs ADFc
•  All ADFc transaction behavior described has considered ADF BC
•  Out of the box ADF BC and ADFc transactions align well
–  One or more operations that are committed/rolled back as a group
–  The commit/rollback is “explicitly” called
•  EJB/JPA supports both “implicit’ (default) and “explicit” commits
–  Implicit commit automatically commits each operation, not the set
• This is orthogonal to the ADFc transaction behavior
–  In switching to explicit commits
• EJB/JPA data control does not yet support ADFc transactions
• See ER 9929224

Conclusion
•  If you only have one data control in your application ,
use <No Controller Transaction>
•  If you have multiple root ADF BC AMs, use the
task flow transaction options
•  Task flows initiating transactions should use an isolated
transaction scope – it's less confusing
•  Always monitor the number of connections your application is
taking out through task flows – this can seriously limit your
application's scalability

Further Reading
•  Task Flow Transaction Fundamentals http://bit.ly/TaskFlowTransFundamentals11
–  Demo 'Completely Separate Transactions' http://bit.ly/ADFTranFundSepTranDemo
–  Demo 'Guarantee Joined Transactions' http://bit.ly/ADFTranFundJoinTranDemo
–  Demo 'No Controller Transaction' http://bit.ly/ADFTranFundNoContDemo
•  ADF Prematurely Terminated Task Flows http://bit.ly/ADFPremTermTaskFlow
•  Page based Prematurely Terminating Task Flow http://bit.ly/ADFPremTermPageTaskFlow
•  ADF BC Application Module Design Next presentation in the training

Oracle ADF Architecture TV - Design - Task Flow Transaction Options

More Related Content

What's hot (20)

Viewers also liked (7)

Similar to Oracle ADF Architecture TV - Design - Task Flow Transaction Options (20)

Recently uploaded (20)

Oracle ADF Architecture TV - Design - Task Flow Transaction Options