The subtle use of task flow "No Controller Transaction" behavior

Question

I'm trying to tease out some subtle points about the Task Flow transactional behavior option "<No Controller Transaction>".
OTN members familiar with task flows in JDev 11g and on wards would know that task flows support options for transactions and data control scope. Some scenarios based on these options:
a) When we pick options such as "Use Existing Transaction" and shared data control scope, the called Bounded Task Flow (BTF) will join the Data Control Frame of its caller. A commit by the child does essentially nothing, a rollback of the child rolls any data changes back to when the child BTF was called (i.e. an implicit save point), while a commit of the parent commits any changes in both the child and parent, and a rollback of a parent loses changes to the child and parent.
A key point to realize about this scenario is the shared data control scope gives both the caller and called BTF the possibility to share a db connection from the connection pool. However this is dependent on the configuration of the underlying services layer. If ADF BC Application Modules (AMs) are used, and they use separate JNDI datasources this wont happen.
b) When we pick options such as "Always Begin New Transaction" and isolated data control scope, the called BTF essentially has its own Data Control Frame separate to that of the caller. A commit or rollback in either the parent/caller or child/called BTF are essentially isolated, or in other words separate transactions.
Similar to the last point but the exact opposite, regardless how the underlying business services are configured, even if ADF BC AMs are used with the same JNDI data source, essentially separate database connections will be taken out assisting the isolated transactional behavior with the database.
This brings me back to my question, of the subtle behavior of the <No Controller Transaction> option. Section 16.4.1 of the Fusion Guide (http://download.oracle.com/docs/cd/E17904_01/web.1111/b31974/taskflows_parameters.htm#CIHIDJBJ) says that when this option is set that "A new data control frame is created without an open transaction." So you could argue this mode is the same as isolated data control scope, and by implication, separate connections will be taken out by the caller/called BTF. Is this correct?
Doesn't this in turn have implications about database read consistency? If we have one BTF participating in a transaction with the database, reading then writing data, and a separate BTF with the <No Controller Transaction> option set, it's possible it wont see the data of the first BTF unless committed before the No Controller Transaction BTF is called and queries it's own dataset correct?
An alternative question which takes a different point of view, is why would you ever want this option, don't the other options cover all the scenarios you could possibly want to use a BTF?
Finally as a separate question based around the same option, presumably an attempt to commit/rollback the Data Control Frame of the associated No Controller Transaction BTF will fail. However what happens if the said BTF attempts to call the Data Control's (not the Data Control Frame's) commit & rollback options? Presumably this will succeed?
Your thoughts and assistance appreciated.
Regards,
CM.

Answer 1

For other readers this reply is a continuation of this thread and another thread: Re: Clarification?: Frank & Lynn's book - task flow "shared" data control scope
Hi Frank
Thanks for your reply. Okay I get the idea that were setting the ADFc options here, that can be overridden by the implementation of data control, and in my specific case that's the ADF BC AM implementation. I've always known that, but the issue became complicated because it didn't make sense what "No Controller Transaction" actually did and when you should use it, and in turn data control frames and their implementation aren't well documented.
I think a key point from your summation is that "No Controller Transaction" in context of ADF BC, with either data control scope option selected, is effectively (as far as we can tell) already covered by the other options. So if our understanding is correct, the recommendation for ADF BC programmers is I think, don't use this option as future programmers/maintainers wont understand the subtlety.
However as you say for users of other data controls, such as those using web services, then it makes sense and possibly should be the only option?
Also regarding your code harvest pg 14 entry on task flow transactions: http://www.oracle.com/technetwork/developer-tools/adf/learnmore/march2011-otn-harvest-351896.pdf
....and the following quote in context of setting the transaction option to Begin New Transaction:
>
When a bounded task flow creates a new transaction, does it also mean it creates a new database connection? No.
>
....I think you need to be a little more careful in this answer, as again it depends on the underlying data control implementation as you point out in this thread. In considering ADF BC, this is correct if you assume only one root AM. However if the BTFs have separate root AMs, this should result in 2 connections and transactions..... well at least I assume it does, though I wonder what will happen if both AMs share the same JNDI data source.... is the framework smart enough to join the connections/transactions in this case?
Also in one of your other code harvests (apologies I can't find which one at the moment) you point out sharing data control scopes is only possible if the BTF data controls have the same name. In context of an ADF BC application, with only one root AM used by multiple BTFs, this of course would be the case. Yet, the obvious implication to your summary of transaction outcomes in this thread, if the developers for whatever reason change the DC name across DataBindings.cpx files sourced from ADF Libraries containing the BTFs, then no, it wont.
Overall the number of variables in this gets really complicated, creating multiple dimensions to the matrix.
Going to your last point, how can the documentation be improved? I think as you say the documentation is right in context of the options for ADFc, but, as the same documentation is included in the Fusion Dev Guide which assumes ADF BC is being used, then it isn't clear enough and can be misleading. It would seem to me, that depending on the underlying data control technology used, then there needs to be documentation that talks about the effect of ADFc task flow behavior options in the context of each technology. And God knows how you describe a scenario where BTFs use DCs that span technologies.
From context of ADF BC, one thing that I've found hard in analyzing all of this is there doesn't seem to be an easy way from the middletier to check how many connections are being taken out from a data source. The FMW Control unfortunately when sampling db connections taken out from a JNDI data source pool, doesn't sample quickly enough to see how many were consumed. Are you aware of some easy method to check the number of the db connections opened/closed?
Finally in considering an Unbounded Task Flow as separate to BTFs, do you have any conclusions about how it participates in the transactions? From what I can determine the UTF lies in it's own data control frame, and is effectively isolated from the BTF transactions, unless, the BTF calls commit/rollback at the ADF BC data control level (as separate to commit/rollback at the data control frame level), and the data control is used both by the UTF and BTF.
As always thanks for your time and assistance.
CM.