Thanks for your feedback and sharing your experience.
In addressing some of your points:
"If it is the same application module in both task flows then i can't
imagine why to have different transactions."
...we make use of the UI Shell which allows users to spawn multiple
tabs, each containing a task flow. It's feasible that each tab can
use the same AM, but allow the user to undertake a different
transaction, so we require the "Always Begin New Transaction" ADFc
functionality. Admittedly most applications wont have this
requirement, it's one provided through the UI Shell and it's multi-tab
approach.
"So I feel transaction management depend mostly on application module design."
Well, kind of (IMHO). I think you first start with the AM design, but
the ADFc task flow options extend (complicate?) the options. I think
you'd be interested in the following [1] OTN forum thread with Frank
Nimphius for a discussion on "No Controller Transaction", and in turn
note the link to an earlier discussion [2] with Steve Muench about AM
pooling and his highlighted concept that AMs can be automatically
nested by the framework:
[1] http://forums.oracle.com/forums/thread.jspa?threadID=2211040&tstart=0
[2] http://forums.oracle.com/forums/thread.jspa?messageID=4022731
"Also transaction options force to have commit or rollback return
activites. So it feels like their usage is mostly to handle pending
changes during navigations."
We've had a few cases where we've created dummy task flow returns
(either commit/rollback) which aren't used at all in the task flow, as
we need to finalize the task flow with a parent navigation action. So
what we do is programatically commit the task flow and then call the
parent navigation action. In hindsight I'm not 100% this is necessary
anymore as I'm back to square 1 in assessing my task flow transaction
options.
Regarding your final comment on your BPMN solution, I'd be keen to
hear your outcomes. You will be spawning a lot of connections, but
whether it really makes a difference is questionable, I guess it
depends on the scalability you're looking for. Again refer to Steve
Muench's replies to the 2nd OTN forum thread above, he has some
experienced insight into AM design.
Cheers,
CM.
> --
> You received this message because you are subscribed to the ADF Enterprise Methodology Group (http://groups.google.com/group/adf-methodology). To unsubscribe send email to adf-methodolo...@googlegroups.com
>
> All content to the ADF EMG lies under the Creative Commons Attribution 3.0 Unported License (http://creativecommons.org/licenses/by/3.0/). Any content sourced must be attributed back to the ADF EMG with a link to the Google Group (http://groups.google.com/group/adf-methodology).
>
To keep transactional flexibility and increased reuse options i have never used the taskflow transaction settings with my customers so far. Most of my customers also use a customized implementation of dynamic tabs, we ensure each tab gets its own transaction by using data control scope is isolated.
Following my tweet last week on setting data control scope at runtime, i had an email discussion this week with frank nimphius and maiko rocha on exactly the same topic. I will forward that email thread to this group. Main conclusion was that being able to set the dc scope and transaction when calling a btf might be a good ER.
Regards,
Steven