Using shared transaction options for nested taskflows even when they use different data sources
Sharing a tip that I learned a couple of days back. Thanks to John Smiljanic for detailing the secret of the magical property that I'm going to talk in this post, also thanks to Ricky Frost who mentioned about this property in one of the discussion.
Use cases here is not something new, rather an age old requirement only: There are two task flows, both use ADF BC, one talks to database-1 and this calls another task flow that talks to database-2. Now the developer wants to leverage the declarative transaction mechanism offered by task flow, that is, a commit call on the task flow return should commit changes in both the flows. Wondering what is big the deal here? Well, here is the short answer. The default task flow implementation assumes that when one a task flow shares transaction with another, both uses same data source. In other words, if the AM used in second task flow(callee) uses different data source, framework will not bother to look up this data source , rather it will ask the AM used in second to reuse the data source looked for the first task flow(calling). At run-time, you may see some object not found error at while executing SQL in second task flow.
There exists a work around solution for the above case. Open the DataBindings.cpx used in the second task flow(callee), scroll down and locate the BC4JDataControl entry for the AM uses in second task flow. In the property inspector, enter some unique literal(logically meaningful) as value for TransactionName. Please see the following xml snippet from DataBindings.cpx.
When this attribute is not defined and a taskflow transaction is started, all BC4J Data Controls in the taskflow share the same transaction/connection if the callee task flow is configured to use existing transaction. When this attribute(TransactionName) is defined and a taskflow transaction is started, the data control will use a different transaction than the taskflow's default transaction mechanism. The named transaction still participates in the taskflow transaction lifecycle, in the same way a Bean Data Control and a BC4J Data Control both participate in a taskflow transaction. that is the data control will still receive commit or rollback messages on task flow return call.
Download
Use cases here is not something new, rather an age old requirement only: There are two task flows, both use ADF BC, one talks to database-1 and this calls another task flow that talks to database-2. Now the developer wants to leverage the declarative transaction mechanism offered by task flow, that is, a commit call on the task flow return should commit changes in both the flows. Wondering what is big the deal here? Well, here is the short answer. The default task flow implementation assumes that when one a task flow shares transaction with another, both uses same data source. In other words, if the AM used in second task flow(callee) uses different data source, framework will not bother to look up this data source , rather it will ask the AM used in second to reuse the data source looked for the first task flow(calling). At run-time, you may see some object not found error at while executing SQL in second task flow.
There exists a work around solution for the above case. Open the DataBindings.cpx used in the second task flow(callee), scroll down and locate the BC4JDataControl entry for the AM uses in second task flow. In the property inspector, enter some unique literal(logically meaningful) as value for TransactionName. Please see the following xml snippet from DataBindings.cpx.
<BC4JDataControl id="EmpAppModuleDataControl" Package="model.emp" FactoryClass="oracle.adf.model.bc4j.DataControlFactoryImpl"
SupportsTransactions="true" SupportsFindMode="true" SupportsRangesize="true"
SupportsResetState="true" SupportsSortCollection="true" Configuration="EmpAppModuleLocal"
syncMode="Immediate" xmlns="http://xmlns.oracle.com/adfm/datacontrol"
TransactionName="XXXTransaction"/>
When this attribute is not defined and a taskflow transaction is started, all BC4J Data Controls in the taskflow share the same transaction/connection if the callee task flow is configured to use existing transaction. When this attribute(TransactionName) is defined and a taskflow transaction is started, the data control will use a different transaction than the taskflow's default transaction mechanism. The named transaction still participates in the taskflow transaction lifecycle, in the same way a Bean Data Control and a BC4J Data Control both participate in a taskflow transaction. that is the data control will still receive commit or rollback messages on task flow return call.
Download
You can download the sample work-space from here.
[ Runs with Oracle JDeveloper 12.1.2.0.0 or higher + HR Schema ].
This has two task flows, each use different AMs connecting two different instance of HR data base. To check the above discussed TransactionName property offerings, do the following:
1. Change the connections to point to two different HR schema. [ Runs with Oracle JDeveloper 12.1.2.0.0 or higher + HR Schema ].
This has two task flows, each use different AMs connecting two different instance of HR data base. To check the above discussed TransactionName property offerings, do the following:
2. Run the main.jsf. It displays two task flows(dept and employee), each talking to different DB, still sharing same transaction. This implementation works because of the TransactionName setting in DataBindings.cpx used in the second task flow
3. In the UI Make changes in both department and employees details(they are coming from different task flows, pointing to different DB)
4. On commit, framework commits both task flows
What if task flows are called dynamically.
ReplyDelete