oracle adf architecture tv - design - task flow transaction options
Post on 11-Nov-2014
220 Views
Preview:
DESCRIPTION
TRANSCRIPT
1 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.
2 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
3 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.
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
4 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.
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
Image: imagerymajestic/ FreeDigitalPhotos.net
5 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.
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
6 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.
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
8 Copyright © 2013, Oracle and/or its affiliates. All rights reserved. 8 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.
Data Control Frame #2
Data Control Frame #1
UTF1
9 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.
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
10 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.
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
11 Copyright © 2013, Oracle and/or its affiliates. All rights reserved. 11 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.
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>
12 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.
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
13 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.
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
14 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.
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)
15 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.
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)
16 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.
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
17 Copyright © 2013, Oracle and/or its affiliates. All rights reserved. 17 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.
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
18 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.
<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
19 Copyright © 2013, Oracle and/or its affiliates. All rights reserved. 19 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.
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!
Image: Ambro / FreeDigitalPhotos.net
20 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.
<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
22 Copyright © 2013, Oracle and/or its affiliates. All rights reserved. 22 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.
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
Image: imagerymajestic/ FreeDigitalPhotos.net
23 Copyright © 2013, Oracle and/or its affiliates. All rights reserved. 23 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.
We need to call a task flow "method call" in its own transaction. Can we
solve this with task flows?
Exercise
Image: imagerymajestic/ FreeDigitalPhotos.net
24 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.
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
25 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.
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
26 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.
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
27 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.
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
28 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.
<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
29 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.
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
30 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.
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();
31 Copyright © 2013, Oracle and/or its affiliates. All rights reserved. 31 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.
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
Image: imagerymajestic/ FreeDigitalPhotos.net
32 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.
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
33 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.
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
34 Copyright © 2013, Oracle and/or its affiliates. All rights reserved. 34 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.
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
Image: imagerymajestic/ FreeDigitalPhotos.net
35 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.
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
36 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.
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
37 Copyright © 2013, Oracle and/or its affiliates. All rights reserved. 37 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.
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-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
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
38 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.
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
39 Copyright © 2013, Oracle and/or its affiliates. All rights reserved. 39 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.
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-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
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
40 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.
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
41 Copyright © 2013, Oracle and/or its affiliates. All rights reserved. 41 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.
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-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
Task Flow Return Commit
Call
Transac-on
Dirty
Update Y = 40
X = 30 Y = 40
Task Flow Return Commit
X = 30 Y = 40
42 Copyright © 2013, Oracle and/or its affiliates. All rights reserved. 42 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.
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>.
Image: Ambro / FreeDigitalPhotos.net
43 Copyright © 2013, Oracle and/or its affiliates. All rights reserved. 43 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.
Exercise Consider this scenario.
Which VO fails and why?
Image: imagerymajestic/ FreeDigitalPhotos.net
44 Copyright © 2013, Oracle and/or its affiliates. All rights reserved. 44 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.
Exercise Consider this scenario.
Why doesn't it fail?
Image: imagerymajestic/ FreeDigitalPhotos.net
45 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.
Program Agenda
• Task Flow Transaction Options • Task Flow Transaction Error Conditions • Task Flow Transaction Finalization • Example Transaction Scenarios • Prematurely Terminated Task Flows • Final Note
46 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.
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
47 Copyright © 2013, Oracle and/or its affiliates. All rights reserved. 47 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.
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
48 Copyright © 2013, Oracle and/or its affiliates. All rights reserved. 48 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.
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
49 Copyright © 2013, Oracle and/or its affiliates. All rights reserved. 49 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.
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
50 Copyright © 2013, Oracle and/or its affiliates. All rights reserved. 50 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.
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
51 Copyright © 2013, Oracle and/or its affiliates. All rights reserved. 51 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.
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 <TaskFlowBean> <taskFlowInit> Task flow /WEB-INF/employees-task-flow.xml#emp-task-flow initialized
52 Copyright © 2013, Oracle and/or its affiliates. All rights reserved. 52 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.
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?
Image: imagerymajestic/ FreeDigitalPhotos.net
53 Copyright © 2013, Oracle and/or its affiliates. All rights reserved. 53 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.
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
54 Copyright © 2013, Oracle and/or its affiliates. All rights reserved. 54 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.
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/employees-task-flow.xml#emp-task-flow initialized <AppModuleImpl> <create> AppModuleImpl created as NESTED AM under AppModule
55 Copyright © 2013, Oracle and/or its affiliates. All rights reserved. 55 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.
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/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
56 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.
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
57 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.
Program Agenda
• Task Flow Transaction Options • Task Flow Transaction Error Conditions • Task Flow Transaction Finalization • Example Transaction Scenarios • Prematurely Terminated Task Flows • Final Note
58 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.
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
59 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.
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
60 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.
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
61 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.
top related