AM pools vs Bounded Task Flows

Question

I'm hoping somebody can give some guidance please? A question around AM pools with the new Bounded Task Flow (BTF) features in JDev 11gPS1, utilising ADF Business Components.
To describe the issue at hand I need to re-assert some ADF facts:
1) Under ADF BC each root AMs can share connection pools by specifying same JDBC URL/JNDI - desired behaviour to best utilise resources of app server and db
2) Each root AMs have separate AM pools. ie. 4 root AMs = 4 AM pools. Nested AMs share the AM pool of their root AM. ie. 1 root AM + 3 nested AMs = 1 AM pool.
3) In previous versions of JDev separate root AMs provided separate transactional capabilities. This is less important now as BTFs can start their own isolated transaction regardless if they use the same root AM.
4) Separate AM pools mean if you have an EO at design time shared among AMs, the EO cache benefit will be ignored if the dependent VOs are used in different AMs.
With these facts in hand, as a separate point we're leaning towards an application architecture with one master app workspace, and every BTF in their own workspace. Our goal is reusability, such that the BTF workspaces can be reused by multiple master apps. In turn each BTF is self contained, including all it's own ADF BC components, including it's own root AM (with the exception EOs will be loaded from a common library).
My question is this. At runtime when the master app makes use of the separate BTF workspaces, each BTF will spawn it's own AM pool. It would seem reasonable that this wasn't the case, that you wouldn't want all these wasted AM pools, but rather somehow nest the BTF AMs.
In talking to two other ACEDs (names will remain anonymous to protect the innocent, unless they decide to follow up this post ;-), the first said via their stress testing that having multiple root AMs didn't prove to be an issue. The assumption being AM pools are lightweight.
The second hinted that maybe the solution is to create at design time a root AM in the master app, then import the BTF business components, and set the BTF AMs as nested AMs of the master app root AM. The assumption being when the master app calls the BTF, and the BTF AM is spawned, as it is spawned through the master app, the master app will nest the BTF AM in the master app root AM (phew, try and say that with a mouth full of crackers).
Any opinions appreciated.
Cheers,
CM.

Answer 1

In thinking about the problem at hand, it does get more complicated if we can't nest the BTF AMs with the master app AM. As stated in the original post:
1) Under ADF BC each root AMs can share connection pools by specifying same JDBC URL/JNDI- desired behaviour to best utilise resources of app server and db
To emphasize, this point is only possible if the root AMs specify the same JDBC URL/JNDI. If the JDBC URL/JNDI names differ, this results is different connection pools for the root AMs - which is undesired. So it's important with separate root AMs to specify the same JDBC URL/JNDI, or alternatively, in the opposite case use nested AMs within a root AM, where the nested AMs through the root AM use the root AMs JDBC URL/JNDI name - and therefore 1 connection pool - the desired behaviour.
(breath)
Now couple these facts with if we have separate master applications, we'd potentially want them to connect to different database schema accounts, which is a reasonable requirement. The idea being you would have your main database schema account which has the schema db objects, then separate "application" accounts, 1 per master app, that are given privs onto the main database schema. In this way you can grant/revoke the exact privs in the db that the "application" account requires, not a blanket access to the main db schema.
So....
(big breath)
The problem we hit is as the separate workspace BTF root AMs have no knowledge of who they will be used by (ie. which master app), and therefore no idea of what "application" db account they will connect to (as that's defined by the master app), they're very unlikely to have the same JDBC URL/JNDI name, which implies separate connections pools.
..and then...
(another big breath)
...it becomes essential to nest the BTF AMs in the master app AM so they're forced to use the parent's JDBC URL/JNDI name - and therefore create one connection pool - the desired behaviour.
(phewwwwwwwwwww)
I hope all that makes sense. It's hard to articulate this succinctly, and from the previous responses, I can see if I skip over some of the details it's already creating confusion. However I think my question (with some back up from other ACEs) is valid and important for large scale reusable application architecture (some how that sentence makes me sound all arrogant and morally superior - not my intention - just trying to sort out our 11g builds before it's too late).
I can think of a few solutions non ADF centric, of which one is to only have a single db "application" account with privs for all master applications, and we can use the db feature to turn on/off dynamic roles per master application to turn on/off privs per application connection (ignoring the fact this is probably slow). Yet I think it's still valid to want a solution in the ADF space, not supported by the db's features.
Any thoughts & opinions appreciated.
Regards,
CM.