Oracle ADF Architecture TV - Design - Task Flow Transaction Options

1 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.


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 #3 Data 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



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



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



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



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?:

–  Calls a Bounded Task Flow #2 •  Data Control Scope?: •  Transaction Option?:

Isolated Always Begin New Transaction Isolated Always Begin New Transaction


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


Task Flow Transac-o

n A

Task Flow Transac-o

n 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


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 –  Calls a Bounded Task Flow #1

•  Data Control Scope: •  Transaction Option: • Calls a Bounded Task Flow #2 •  Data Control Scope: •  Transaction Option:

Isolated Always Begin New Transaction

Shared

Always Use Existing Transaction



Unbounded Task Flow Bounded Task Flow #1 Isolated Data Control Scope


Task Flow Transac-o

n 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


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


X = 30 Y = 40


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 –  Calls a Bounded Task Flow #1

•  Data Control Scope: Isolated •  Transaction Option: <No Controller Transaction>

–  Calls a Bounded Task Flow #2 •  Data Control Scope: Shared •  Transaction Option: Use Existing Transaction if Possible



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-o

n 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


Call

Transac-on

Dirty

Update Y = 40

X = 30 Y = 40


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

•  Task Flow Transaction Options •  Task Flow Transaction Error Conditions •  Task Flow Transaction Finalization •  Example Transaction Scenarios •  Prematurely Terminated Task Flows •  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/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/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 <TaskFlowBean> <taskFlowInit> Task flow /WEB-INF/employees-task-flow.xml#emp-task-flow initialized


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> <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/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> <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

•  Task Flow Transaction Options •  Task Flow Transaction Error Conditions •  Task Flow Transaction Finalization •  Example Transaction Scenarios •  Prematurely Terminated Task Flows •  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


Technology

Oracle ADF Architecture TV - Design - Task Flow Transaction Options