Root Application Module

i understand that we can't extend and substitute the root application module for a page. However, I am not sure how to tell if the AM I am working with is a root AM, actually I am not sure what a root AM is either. I tried extending PsrAM which is under oracle.apps.ap.payments.psr.server. It is the AM that is referred to from PsrPG.xml.
So how do I tell if this is the root AM?
Thanks for any help you can give!
Dennis

Dennis
In addition to what chandra mentioned. Your saying that root AM cant be extended is not 100% correct
i understand that we can't extend and substitute the root application module for a pageWe can extend root AM as well provided that page doesnot have any LOV in it.
However as a workaround you can create a custom Application Module in Jdev and add it to page with the help of StackLayout Region.
Thanks
AJ

Similar Messages

Best Practice to use a single root Application Module?

I was reading in another thread that it may be a good idea to have all application modules nested within a single root application module (AM) so that there is only 1 session maintained for the root AM, versus an individual session for each AM. Is this a best practice? If yes, should the root AM be a skeleton AM (minimal customer service methods), or, should you select the most heavily used AM and nest the other AM's underneath of it?
In my case, I currenlty have 2 AM's (and will have 3 AM's in the future) each representing a different set of use cases withn the application (i.e., one supports users searches / shopping cart-like functionality, and the second supports an enrollment process.) It could be the case that a user only accesses pages on the web site to do searches (first AM), or only to do enrollment (2nd AM), or, they may access pages of the site that access both AM's. Right now I have 2 separate AM's that are not nested. Should I nest the AM's and define a root AM?
thanks

Hi javaX
The main physical effect of having 2 separate AMs is that they have their own transactions with the database, and presumably sit in the application module pool as their own instances consuming connections from the connection pool. Alternatively a single root AM with 2 nested AMs share a single transaction through the root AM; only the root AM controls the transaction in this scenario.
As such it's a question of do you need separate transactions or will one suffice?
How you group your EOs/VOs etc within the AMs is up to you, but usually falls into logical groups such as you have done. If a single transaction is fine, instead of creating multiple AMs, you could instead just create logical package structures instead. Neither method is right or wrong, they're just different ways of structuring your application.
When you create a nested AM structure, within your ViewController project in the Data Control Palette you'll actually see 3 data controls mapped to each AM. In addition expanding the root AM data control, you'll see the nested AMs again. Create a dummy project with a nested AM structure and you'll see what I mean.
If you base your page definitions on anything from the root AM and it's children in the Data Control Palette, this will work on the root AM's transaction.
If you base your page definitions on something from one of the other AM data controls that isn't inside the main root AM in the Data Control Palette, instead of using the root AM's transaction, the separate child AM will be treated as root AM and will have its own transaction.
The thing to care of when developing web pages is to consistently use the AM and it's nested AMs, or the child AMs directly with their separate transactions, otherwise it might cause a bit of a nightmare debugging situation later on when the same application is locking and blocking on the same records from 2 separate AM transactions.
Hope this helps.
CM.

Root Application Module connecting to 2 databases technologies

I have an application which needs to connect to 2 different databases.
I managed to get access to each databases in their own respective Application Modules.
In order to achieve that, I created a new ViewObject within the "oracle" model, and still used the "MySQL" query. Using the jbo.envinfoprovider property, I can force the Application module to connect to the appropriate database, MySQL in this case.
Now, my problem is that I need to have a Root application module that will use BOTH "child" application module and eventually BOTH database connections. At the moment, I can only use one at a time. Using the jbo.envinfoprovider property of the ROOT application module allows me to select which of the 2 database I want to use, but I need both.
To put it in a tree-like structure, here's what I want to achieve :
ROOT (Oracle + MySQL)
|
|__ AppModule1 (Oracle)
| |
| |__ View1
| |__ View2
|
|__ AppModule2 (MySQL)
|
|_ View3

What I mean is if I deploy the application on the integrated weblogic server, using the default navigation flow defined in the adfc-config.xml file, when I reach the "forensic" page, it will try to "read" from both database and fail at reading the second database.
The page displays the following :
1- a table containing the records from the Oracle database (3 columns=> ID, pattern, solution)
2- an adf_form used to populate the above table :
- the ID is bound to a database trigger, so is set to readonly
- the solution is a text input field
- the Pattern is a LoV, based on the data found on the MySQL database.
If I test the page from the "forensic.jspx" itself (by right-clicking and selecting "Run"), I can manage the data just fine (I can do any CRUD operations I want)
on the other hand, if I go to the "adfc-config.xml" file and (right-click and then select "Run"), the page will only read one of the two database (I can control which one, by changing the jbo.envinfoprovider property of my application module)
Hope this helps understand what I am trying to achieve.
Thanks !

Painting one root Application Module to rule them all

hi
The description below uses the same MyApplicationModuleListener approach as I describe in the forum thread "painting a picture of Application Module pooling".
Another example review of Application Module pools behaviour is the blog post by Chris Muir, "JDev 11g, Task Flows & ADF BC – one root Application Module to rule them all?".
That post also says "... we'll have trouble discerning what the ADF BC layer is actually doing underneath the task flow transaction options. ...", where the approach below might help alleviate some of that discerning trouble.
And about "... By deduction as there are no other log entries, this second instance of Root1AppModule must be nested under the root Root1AppModule? ..." more information will be logged, so less deduction is required.
The blog post describes an application similar to this one (which is using the HR.EMPLOYEES table) created using JDeveloper 11.1.1.6.0
at http://www.consideringred.com/files/oracle/2012/OneSizeOneRootAMApp-v0.01.zip
It uses somewhat different names than the blog post, and it has two sets of task-flows so that no transaction configuration changes are required to review the behaviour.
When a MyApplicationModuleListener approach is introduced (with minor changes, mostly configuration, using JAR files available in MyApplicationModuleListenerApp-v0.03.zip) it results in the application available
at http://www.consideringred.com/files/oracle/2012/OneSizeOneRootAMApp-v0.02.zip
Using this, the (chained) "No Controller Transaction" scenario's result in similar logging like this:
[C][L][r1001][(ctx31) /faces : /firstIndex] setRequestInfoPrefix() : extra [GET with 3 parameters (partial request false) (initial render true) (postback true)]
[C][L][r1002][(ctx32) /faces : /firstIndex] setRequestInfoPrefix() : extra [GET with 3 parameters (partial request false) (initial render true) (postback true)]
[C][L][r1001][(ctx31) /faces : /firstIndex] onAfterRequest() : no ApplicationPools
[C][L][r1002][(ctx32) /faces : /firstIndex] onAfterRequest() : no ApplicationPools
[C][L][r1003][(ctx31) /faces : /firstIndex] setRequestInfoPrefix() : extra [POST with 5 parameters (partial request false) (initial render false) (postback true)]
[C][L][r1003][(ctx31) /faces : /firstIndex] onNewConstruction() : [(am501) FirstAppModuleImpl_1 (not root) parent = (null)]
[C][L][r1003][(ctx31) /faces : /firstIndex] onActivate() : [(am501) FirstAppModule (is root)](session version 11.1.1.61.92 oracle.jbo.server.SessionImpl@16cbcec)
[C][L][r1003][(ctx31) /faces : /firstIndex] onCreate() : [(am501) FirstAppModule (is root)]
########FirstAppModuleImpl.create() called. AM isRoot() = true
[C][L][r1003][(ctx31) /faces : /firstIndex] onAfterConnect() : [(am501) FirstAppModule (is root)]
[C][L][r1003][(ctx31) /faces : /firstIndex] onPrepareSession() : [(am501) FirstAppModule (is root)]
########FirstAppModuleImpl.prepareSession() called. AM isRoot() = true
[C][L][r1003][(ctx31) /faces : /firstIndex] onAfterDoPoolMessage() : [(am501) FirstAppModule (is root)][(ses101) MESSAGE_TYPE_USING (1) STATUS_SUCCESS (8) (rp 4)]
[C][L][r1003][(ctx31) /faces : /firstIndex] onPassivateState() : 5 : [(am501) FirstAppModule (is root)] pId = -1, pClientData = null, pFlags = PASSIVATE_HINT_FLAG (16)
[C][L][r1003][(ctx31) /faces : /firstIndex] onAfterDoPoolMessage() : [(am501) FirstAppModule (is root)][(ses101) MESSAGE_TYPE_RELEASING (2) STATUS_SUCCESS (8) (rp 3)]
[C][L][r1003][(ctx31) /faces : /firstIndex] onNewShortId() : pNewShortId = ds81, pId = java:comp/env/jdbc/connHRDS - com.bea:ServerRuntime=DefaultServer,Name=OneSizeOneRootAMApp@connHR@connHR,ApplicationRuntime=OneSizeOneRootAMApp,Type=JDBCDataSourceRuntime
[C][L][r1003][(ctx31) /faces : /firstIndex] onAfterRequest() : 1 : ApplicationPool = onesizeonerootamapp.model.FirstAppModuleLocal
(ap21)[cre 1; rem 0; act 0; pas 0; co 1; ci 1; ref reu 0; ref rec 0; unr rec 0; fail 0; tot am 1; max am 1; avg am 1; tot ava 1; avg ava 1; avg una 0; tot ref 1; ses 1; avg ses 1]
(ds81)[cur cap 1; avai 0; unav 1; cp hig 1; ac cur 1; ac avg 0; ac hig 1; co del 168; co tot 1; res req 1; fai res 0; fai rec 0; h avai 1; h unav 1; lea co 0; psc acc 0; psc add 0; psc csi 0; psc del 0; psc hit 0; psc mis 0; wfc cur 0; wfc fai 0; wfc hig 0; wfc tot 0; wse hig 0]
[C][L][r1004][(ctx31) /faces : /firstam-btf/empVoFirstViPage] setRequestInfoPrefix() : extra [GET with 5 parameters (partial request true) (initial render false) (postback true)]
[C][L][r1004][(ctx31) /faces : /firstam-btf/empVoFirstViPage] onAfterDoPoolMessage() : [(am501) FirstAppModule (is root)][(ses101) MESSAGE_TYPE_USING (1) STATUS_SUCCESS (8) (rp 4)]
[C][L][r1004][(ctx31) /faces : /firstam-btf/empVoFirstViPage] onPassivateState() : 5 : [(am501) FirstAppModule (is root)] pId = -1, pClientData = null, pFlags = PASSIVATE_HINT_FLAG (16)
[C][L][r1004][(ctx31) /faces : /firstam-btf/empVoFirstViPage] onAfterDoPoolMessage() : [(am501) FirstAppModule (is root)][(ses101) MESSAGE_TYPE_RELEASING (2) STATUS_SUCCESS (8) (rp 3)]
[C][L][r1004][(ctx31) /faces : /firstam-btf/empVoFirstViPage] onAfterRequest() : 1 : ApplicationPool = onesizeonerootamapp.model.FirstAppModuleLocal
(ap21)[cre 1; rem 0; act 0; pas 0; co 2; ci 2; ref reu 1; ref rec 0; unr rec 0; fail 0; tot am 1; max am 1; avg am 1; tot ava 1; avg ava 1; avg una 0; tot ref 1; ses 1; avg ses 1]
(ds81)[cur cap 1; avai 0; unav 1; cp hig 1; ac cur 1; ac avg 0; ac hig 1; co del 168; co tot 1; res req 1; fai res 0; fai rec 0; h avai 1; h unav 1; lea co 0; psc acc 2; psc add 2; psc csi 2; psc del 0; psc hit 0; psc mis 2; wfc cur 0; wfc fai 0; wfc hig 0; wfc tot 0; wse hig 0]
[C][L][r1005][(ctx31) /faces : /firstam-btf/empVoFirstViPage] setRequestInfoPrefix() : extra [POST with 55 parameters (partial request false) (initial render false) (postback true)]
[C][L][r1005][(ctx31) /faces : /firstam-btf/empVoFirstViPage] onAfterDoPoolMessage() : [(am501) FirstAppModule (is root)][(ses101) MESSAGE_TYPE_USING (1) STATUS_SUCCESS (8) (rp 4)]
[C][L][r1005][(ctx31) /faces : /firstam-btf/empVoFirstViPage] onNewConstruction() : [(am502) SecondAppModuleImpl_154 (not root) parent = (null)]
[C][L][r1005][(ctx31) /faces : /firstam-btf/empVoFirstViPage] onActivate() : [(am502) SecondAppModule (is root)](session version 11.1.1.61.92 oracle.jbo.server.SessionImpl@8add89)
[C][L][r1005][(ctx31) /faces : /firstam-btf/empVoFirstViPage] onCreate() : [(am502) SecondAppModule (is root)]
########SecondAppModuleImpl.create() called. AM isRoot() = true
[C][L][r1005][(ctx31) /faces : /firstam-btf/empVoFirstViPage] onAfterConnect() : [(am502) SecondAppModule (is root)]
[C][L][r1005][(ctx31) /faces : /firstam-btf/empVoFirstViPage] onPrepareSession() : [(am502) SecondAppModule (is root)]
########SecondAppModuleImpl.prepareSession() called. AM isRoot() = true
[C][L][r1005][(ctx31) /faces : /firstam-btf/empVoFirstViPage] onAfterDoPoolMessage() : [(am502) SecondAppModule (is root)][(ses101) MESSAGE_TYPE_USING (1) STATUS_SUCCESS (8) (rp 4)]
[C][L][r1005][(ctx31) /faces : /firstam-btf/empVoFirstViPage] onPassivateState() : 5 : [(am501) FirstAppModule (is root)] pId = -1, pClientData = null, pFlags = PASSIVATE_HINT_FLAG (16)
[C][L][r1005][(ctx31) /faces : /firstam-btf/empVoFirstViPage] onAfterDoPoolMessage() : [(am501) FirstAppModule (is root)][(ses101) MESSAGE_TYPE_RELEASING (2) STATUS_SUCCESS (8) (rp 3)]
[C][L][r1005][(ctx31) /faces : /firstam-btf/empVoFirstViPage] onPassivateState() : 5 : [(am502) SecondAppModule (is root)] pId = -1, pClientData = null, pFlags = PASSIVATE_HINT_FLAG (16)
[C][L][r1005][(ctx31) /faces : /firstam-btf/empVoFirstViPage] onAfterDoPoolMessage() : [(am502) SecondAppModule (is root)][(ses101) MESSAGE_TYPE_RELEASING (2) STATUS_SUCCESS (8) (rp 3)]
[C][L][r1005][(ctx31) /faces : /firstam-btf/empVoFirstViPage] onAfterRequest() : 1 : ApplicationPool = onesizeonerootamapp.model.FirstAppModuleLocal
(ap21)[cre 1; rem 0; act 0; pas 0; co 3; ci 3; ref reu 2; ref rec 0; unr rec 0; fail 0; tot am 1; max am 1; avg am 1; tot ava 1; avg ava 1; avg una 0; tot ref 1; ses 1; avg ses 1]
(ds81)[cur cap 2; avai 0; unav 2; cp hig 2; ac cur 2; ac avg 0; ac hig 2; co del 122; co tot 2; res req 2; fai res 0; fai rec 0; h avai 1; h unav 2; lea co 0; psc acc 2; psc add 2; psc csi 2; psc del 0; psc hit 0; psc mis 2; wfc cur 0; wfc fai 0; wfc hig 0; wfc tot 0; wse hig 0]
[C][L][r1005][(ctx31) /faces : /firstam-btf/empVoFirstViPage] onAfterRequest() : 2 : ApplicationPool = onesizeonerootamapp.model.SecondAppModuleLocal
(ap22)[cre 1; rem 0; act 0; pas 0; co 1; ci 1; ref reu 0; ref rec 0; unr rec 0; fail 0; tot am 1; max am 1; avg am 1; tot ava 1; avg ava 1; avg una 0; tot ref 1; ses 1; avg ses 1]
(ds81)[cur cap 2; avai 0; unav 2; cp hig 2; ac cur 2; ac avg 0; ac hig 2; co del 122; co tot 2; res req 2; fai res 0; fai rec 0; h avai 1; h unav 2; lea co 0; psc acc 2; psc add 2; psc csi 2; psc del 0; psc hit 0; psc mis 2; wfc cur 0; wfc fai 0; wfc hig 0; wfc tot 0; wse hig 0]
[C][L][r1006][(ctx31) /faces : /secondam-btf/empVoSecondViPage] setRequestInfoPrefix() : extra [GET with 5 parameters (partial request true) (initial render false) (postback true)]
[C][L][r1006][(ctx31) /faces : /secondam-btf/empVoSecondViPage] onAfterDoPoolMessage() : [(am502) SecondAppModule (is root)][(ses101) MESSAGE_TYPE_USING (1) STATUS_SUCCESS (8) (rp 4)]
[C][L][r1006][(ctx31) /faces : /secondam-btf/empVoSecondViPage] onPassivateState() : 5 : [(am502) SecondAppModule (is root)] pId = -1, pClientData = null, pFlags = PASSIVATE_HINT_FLAG (16)
[C][L][r1006][(ctx31) /faces : /secondam-btf/empVoSecondViPage] onAfterDoPoolMessage() : [(am502) SecondAppModule (is root)][(ses101) MESSAGE_TYPE_RELEASING (2) STATUS_SUCCESS (8) (rp 3)]
[C][L][r1006][(ctx31) /faces : /secondam-btf/empVoSecondViPage] onAfterRequest() : 1 : ApplicationPool = onesizeonerootamapp.model.FirstAppModuleLocal
(ap21)[cre 1; rem 0; act 0; pas 0; co 3; ci 3; ref reu 2; ref rec 0; unr rec 0; fail 0; tot am 1; max am 1; avg am 1; tot ava 1; avg ava 1; avg una 0; tot ref 1; ses 1; avg ses 1]
(ds81)[cur cap 2; avai 0; unav 2; cp hig 2; ac cur 2; ac avg 0; ac hig 2; co del 122; co tot 2; res req 2; fai res 0; fai rec 0; h avai 1; h unav 2; lea co 0; psc acc 4; psc add 4; psc csi 4; psc del 0; psc hit 0; psc mis 4; wfc cur 0; wfc fai 0; wfc hig 0; wfc tot 0; wse hig 0]
[C][L][r1006][(ctx31) /faces : /secondam-btf/empVoSecondViPage] onAfterRequest() : 2 : ApplicationPool = onesizeonerootamapp.model.SecondAppModuleLocal
(ap22)[cre 1; rem 0; act 0; pas 0; co 2; ci 2; ref reu 1; ref rec 0; unr rec 0; fail 0; tot am 1; max am 1; avg am 1; tot ava 1; avg ava 1; avg una 0; tot ref 1; ses 1; avg ses 1]
(ds81)[cur cap 2; avai 0; unav 2; cp hig 2; ac cur 2; ac avg 0; ac hig 2; co del 122; co tot 2; res req 2; fai res 0; fai rec 0; h avai 1; h unav 2; lea co 0; psc acc 4; psc add 4; psc csi 4; psc del 0; psc hit 0; psc mis 4; wfc cur 0; wfc fai 0; wfc hig 0; wfc tot 0; wse hig 0]The "Always Begin New Transaction and Always Use Existing transaction" scenario results in logging like this:
[C][L][r1001][(ctx31) /faces : /secondIndex] setRequestInfoPrefix() : extra [GET with 3 parameters (partial request false) (initial render true) (postback true)]
[C][L][r1002][(ctx32) /faces : /secondIndex] setRequestInfoPrefix() : extra [GET with 3 parameters (partial request false) (initial render true) (postback true)]
[C][L][r1001][(ctx31) /faces : /secondIndex] onAfterRequest() : no ApplicationPools
[C][L][r1002][(ctx32) /faces : /secondIndex] onAfterRequest() : no ApplicationPools
[C][L][r1003][(ctx32) /faces : /secondIndex] setRequestInfoPrefix() : extra [POST with 5 parameters (partial request false) (initial render false) (postback true)]
[C][L][r1003][(ctx32) /faces : /secondIndex] onNewConstruction() : [(am501) FirstAppModuleImpl_1 (not root) parent = (null)]
[C][L][r1003][(ctx32) /faces : /secondIndex] onActivate() : [(am501) FirstAppModule (is root)](session version 11.1.1.61.92 oracle.jbo.server.SessionImpl@1d90a2c)
[C][L][r1003][(ctx32) /faces : /secondIndex] onCreate() : [(am501) FirstAppModule (is root)]
########FirstAppModuleImpl.create() called. AM isRoot() = true
[C][L][r1003][(ctx32) /faces : /secondIndex] onAfterConnect() : [(am501) FirstAppModule (is root)]
[C][L][r1003][(ctx32) /faces : /secondIndex] onPrepareSession() : [(am501) FirstAppModule (is root)]
########FirstAppModuleImpl.prepareSession() called. AM isRoot() = true
[C][L][r1003][(ctx32) /faces : /secondIndex] onAfterDoPoolMessage() : [(am501) FirstAppModule (is root)][(ses101) MESSAGE_TYPE_USING (1) STATUS_SUCCESS (8) (rp 4)]
[C][L][r1003][(ctx32) /faces : /secondIndex] onNewConstruction() : [(am502) FirstAppModuleImpl_2 (not root) parent = (null)]
[C][L][r1003][(ctx32) /faces : /secondIndex] onSetParent() : 2 : [(am502) onesizeonerootamapp_model_FirstAppModule (not root) parent = (null)] parent = [(am501) FirstAppModule (is root)]
[C][L][r1003][(ctx32) /faces : /secondIndex] onCreate() : [(am502) onesizeonerootamapp_model_FirstAppModule (not root) parent = [(am501) FirstAppModule (is root)]]
########FirstAppModuleImpl.create() called. AM isRoot() = false
[C][L][r1003][(ctx32) /faces : /secondIndex] onPassivateState() : 5 : [(am501) FirstAppModule (is root)] pId = -1, pClientData = null, pFlags = PASSIVATE_HINT_FLAG (16)
[C][L][r1003][(ctx32) /faces : /secondIndex] onAfterDoPoolMessage() : [(am501) FirstAppModule (is root)][(ses101) MESSAGE_TYPE_RELEASING (2) STATUS_SUCCESS (8) (rp 3)]
[C][L][r1003][(ctx32) /faces : /secondIndex] onNewShortId() : pNewShortId = ds81, pId = java:comp/env/jdbc/connHRDS - com.bea:ServerRuntime=DefaultServer,Name=OneSizeOneRootAMApp@connHR@connHR,ApplicationRuntime=OneSizeOneRootAMApp,Type=JDBCDataSourceRuntime
[C][L][r1003][(ctx32) /faces : /secondIndex] onAfterRequest() : 1 : ApplicationPool = onesizeonerootamapp.model.FirstAppModuleLocal
(ap21)[cre 1; rem 0; act 0; pas 0; co 1; ci 1; ref reu 0; ref rec 0; unr rec 0; fail 0; tot am 1; max am 1; avg am 1; tot ava 1; avg ava 1; avg una 0; tot ref 1; ses 1; avg ses 1]
(ds81)[cur cap 1; avai 0; unav 1; cp hig 1; ac cur 1; ac avg 0; ac hig 1; co del 75; co tot 1; res req 1; fai res 0; fai rec 0; h avai 1; h unav 1; lea co 0; psc acc 0; psc add 0; psc csi 0; psc del 0; psc hit 0; psc mis 0; wfc cur 0; wfc fai 0; wfc hig 0; wfc tot 0; wse hig 0]
[L-before][L][(ctx32) /faces : /firstam-tx-btf/empVoFirstViPage] onAfterDoPoolMessage() : [(am501) FirstAppModule (is root)][(ses101) MESSAGE_TYPE_USING (1) STATUS_SUCCESS (8) (rp 4)]
[C][L][r1004][(ctx32) /faces : /firstam-tx-btf/empVoFirstViPage] setRequestInfoPrefix() : extra [GET with 5 parameters (partial request true) (initial render false) (postback true)]
[C][L][r1004][(ctx32) /faces : /firstam-tx-btf/empVoFirstViPage] onPassivateState() : 5 : [(am501) FirstAppModule (is root)] pId = -1, pClientData = null, pFlags = PASSIVATE_HINT_FLAG (16)
[C][L][r1004][(ctx32) /faces : /firstam-tx-btf/empVoFirstViPage] onAfterDoPoolMessage() : [(am501) FirstAppModule (is root)][(ses101) MESSAGE_TYPE_RELEASING (2) STATUS_SUCCESS (8) (rp 3)]
[C][L][r1004][(ctx32) /faces : /firstam-tx-btf/empVoFirstViPage] onAfterRequest() : 1 : ApplicationPool = onesizeonerootamapp.model.FirstAppModuleLocal
(ap21)[cre 1; rem 0; act 0; pas 0; co 2; ci 2; ref reu 1; ref rec 0; unr rec 0; fail 0; tot am 1; max am 1; avg am 1; tot ava 1; avg ava 1; avg una 0; tot ref 1; ses 1; avg ses 1]
(ds81)[cur cap 1; avai 0; unav 1; cp hig 1; ac cur 1; ac avg 0; ac hig 1; co del 75; co tot 1; res req 1; fai res 0; fai rec 0; h avai 1; h unav 1; lea co 0; psc acc 2; psc add 2; psc csi 2; psc del 0; psc hit 0; psc mis 2; wfc cur 0; wfc fai 0; wfc hig 0; wfc tot 0; wse hig 0]
[L-before][L][(ctx31) /faces : /firstam-tx-btf/empVoFirstViPage] onAfterDoPoolMessage() : [(am501) FirstAppModule (is root)][(ses101) MESSAGE_TYPE_USING (1) STATUS_SUCCESS (8) (rp 4)]
[C][L][r1005][(ctx31) /faces : /firstam-tx-btf/empVoFirstViPage] setRequestInfoPrefix() : extra [POST with 55 parameters (partial request false) (initial render false) (postback true)]
[C][L][r1005][(ctx31) /faces : /firstam-tx-btf/empVoFirstViPage] onPassivateStateForUndo() : [(am501) FirstAppModule (is root)] pId = null, pClientData = null, pFlags = unknown passivation flags (0)
[C][L][r1005][(ctx31) /faces : /firstam-tx-btf/empVoFirstViPage] onPassivateState() : 2 : [(am501) FirstAppModule (is root)] pClientData = null, pFlags = PASSIVATE_UNDO_FLAG, PASSIVATE_TO_STACK_FLAG (40)
[C][L][r1005][(ctx31) /faces : /firstam-tx-btf/empVoFirstViPage] onPassivateConnectionState() : [(am502) onesizeonerootamapp_model_FirstAppModule (not root) parent = [(am501) FirstAppModule (is root)]] pDoc = (name = #document, doc elem = null), pParent = (name = CONN)
[C][L][r1005][(ctx31) /faces : /firstam-tx-btf/empVoFirstViPage] onPassivateConnectionState() : [(am501) FirstAppModule (is root)] pDoc = (name = #document, doc elem = null), pParent = (name = CONN)
[C][L][r1005][(ctx31) /faces : /firstam-tx-btf/empVoFirstViPage] onPrepareForPassivation() : [(am501) FirstAppModule (is root)] pOut = (name = #document, doc elem = null) pParent = (name = AM)
[C][L][r1005][(ctx31) /faces : /firstam-tx-btf/empVoFirstViPage] onPrepareForPassivation() : [(am502) onesizeonerootamapp_model_FirstAppModule (not root) parent = [(am501) FirstAppModule (is root)]] pOut = (name = #document, doc elem = null) pParent = (name = AM)
[C][L][r1005][(ctx31) /faces : /firstam-tx-btf/empVoFirstViPage] onPassivateState() : 3 : [(am502) onesizeonerootamapp_model_FirstAppModule (not root) parent = [(am501) FirstAppModule (is root)]] pDoc = (name = #document, doc elem = null), pParent = (name = AM)
[C][L][r1005][(ctx31) /faces : /firstam-tx-btf/empVoFirstViPage] onPassivateState() : 3 : [(am501) FirstAppModule (is root)] pDoc = (name = #document, doc elem = null), pParent = (name = AM)
[C][L][r1005][(ctx31) /faces : /firstam-tx-btf/empVoFirstViPage] onNewConstruction() : [(am503) SecondAppModuleImpl_155 (not root) parent = (null)]
[C][L][r1005][(ctx31) /faces : /firstam-tx-btf/empVoFirstViPage] onSetParent() : 2 : [(am503) onesizeonerootamapp_model_SecondAppModule (not root) parent = (null)] parent = [(am501) FirstAppModule (is root)]
[C][L][r1005][(ctx31) /faces : /firstam-tx-btf/empVoFirstViPage] onCreate() : [(am503) onesizeonerootamapp_model_SecondAppModule (not root) parent = [(am501) FirstAppModule (is root)]]
########SecondAppModuleImpl.create() called. AM isRoot() = false
[C][L][r1005][(ctx31) /faces : /firstam-tx-btf/empVoFirstViPage] onPassivateState() : 5 : [(am501) FirstAppModule (is root)] pId = -1, pClientData = null, pFlags = PASSIVATE_HINT_FLAG (16)
[C][L][r1005][(ctx31) /faces : /firstam-tx-btf/empVoFirstViPage] onAfterDoPoolMessage() : [(am501) FirstAppModule (is root)][(ses101) MESSAGE_TYPE_RELEASING (2) STATUS_SUCCESS (8) (rp 3)]
[C][L][r1005][(ctx31) /faces : /firstam-tx-btf/empVoFirstViPage] onAfterRequest() : 1 : ApplicationPool = onesizeonerootamapp.model.FirstAppModuleLocal
(ap21)[cre 1; rem 0; act 0; pas 0; co 3; ci 3; ref reu 2; ref rec 0; unr rec 0; fail 0; tot am 1; max am 1; avg am 1; tot ava 1; avg ava 1; avg una 0; tot ref 1; ses 1; avg ses 1]
(ds81)[cur cap 2; avai 1; unav 1; cp hig 2; ac cur 1; ac avg 0; ac hig 2; co del 79; co tot 2; res req 2; fai res 0; fai rec 0; h avai 1; h unav 2; lea co 0; psc acc 3; psc add 3; psc csi 3; psc del 0; psc hit 0; psc mis 3; wfc cur 0; wfc fai 0; wfc hig 0; wfc tot 0; wse hig 0]
[L-before][L][(ctx31) /faces : /secondam-tx-btf/empVoSecondViPage] onAfterDoPoolMessage() : [(am501) FirstAppModule (is root)][(ses101) MESSAGE_TYPE_USING (1) STATUS_SUCCESS (8) (rp 4)]
[C][L][r1006][(ctx31) /faces : /secondam-tx-btf/empVoSecondViPage] setRequestInfoPrefix() : extra [GET with 5 parameters (partial request true) (initial render false) (postback true)]
[C][L][r1006][(ctx31) /faces : /secondam-tx-btf/empVoSecondViPage] onPassivateState() : 5 : [(am501) FirstAppModule (is root)] pId = -1, pClientData = null, pFlags = PASSIVATE_HINT_FLAG (16)
[C][L][r1006][(ctx31) /faces : /secondam-tx-btf/empVoSecondViPage] onAfterDoPoolMessage() : [(am501) FirstAppModule (is root)][(ses101) MESSAGE_TYPE_RELEASING (2) STATUS_SUCCESS (8) (rp 3)]
[C][L][r1006][(ctx31) /faces : /secondam-tx-btf/empVoSecondViPage] onAfterRequest() : 1 : ApplicationPool = onesizeonerootamapp.model.FirstAppModuleLocal
(ap21)[cre 1; rem 0; act 0; pas 0; co 4; ci 4; ref reu 3; ref rec 0; unr rec 0; fail 0; tot am 1; max am 1; avg am 1; tot ava 1; avg ava 1; avg una 0; tot ref 1; ses 1; avg ses 1]
(ds81)[cur cap 2; avai 1; unav 1; cp hig 2; ac cur 1; ac avg 0; ac hig 2; co del 79; co tot 2; res req 2; fai res 0; fai rec 0; h avai 1; h unav 2; lea co 0; psc acc 5; psc add 3; psc csi 3; psc del 0; psc hit 1; psc mis 4; wfc cur 0; wfc fai 0; wfc hig 0; wfc tot 0; wse hig 0]This seems to confirm more explicitly some of the observations in the blog post, and at the same time might add some additional insight into what the framework is doing.
Suggestions to improve such MyApplicationModuleListener approach (or an alternative approach) are welcome.
many thanks
Jan Vervecken

fyi
Some additional features were added in the JAR files available
in http://www.consideringred.com/files/oracle/2013/MyApplicationModuleListenerApp-v0.05.zip
Like line numbers, or a queryOneRecord() method to support logging the database session SID, or a TaskFlowInfoHelper class to allow logging task-flow transaction options or DataControlFrame information.
If these JAR files are used, it results in the modified example application
at http://www.consideringred.com/files/oracle/2013/OneSizeOneRootAMApp-v0.03.zip
For the same scenarios (using OneSizeOneRootAMApp-v0.03.zip), the resulting logging can be found in these files:
- "maml-log-20130113-jdev111160-nctx.txt" : when using JDeveloper 11.1.1.6.0 and the chained "No Controller Transaction" scenario :
[0002][C][L][r1001][(ctx31) /faces : /firstIndex] logContextInformation() :
[0003]#{a_versionBean.appVersionInfo} = OneSizeOneRootAMApp v0.03 : oracle.jbo.Version = 11.1.1.61.92
[0007][C][L][r1002][(ctx32) /faces : /firstIndex] onAfterPrepareModel() : task-flow = (no current TaskFlowId) (unbounded task-flow pages)
[0008]transaction type = (no current TaskFlowId), DC scope = (no current TaskFlowId), DC frame = e1o4lmuw3_2, open transaction = null, is transaction dirty = false
[0044][C][L][r1005][(ctx32) /faces : /firstam-btf/empVoFirstViPage] onAfterPrepareModel() : task-flow = /WEB-INF/btf/firstam-btf.xml#firstam-btf (no page-fragments)
[0045]transaction type = -No Controller Transaction-, DC scope = shared DataControlScopeType, DC frame = e1o4lmuw3_2, open transaction = null, is transaction dirty = false
[0046][C][L][r1005][(ctx32) /faces : /firstam-btf/empVoFirstViPage] onAfterPrepareModel() : task-flow = /WEB-INF/btf/secondam-btf.xml#secondam-btf (no page-fragments)
[0047]transaction type = -No Controller Transaction-, DC scope = shared DataControlScopeType, DC frame = e1o4lmuw3_2, open transaction = null, is transaction dirty = true
[0057][C][L][r1005][(ctx32) /faces : /firstam-btf/empVoFirstViPage] onAfterDoPoolMessage() : [(am501) FirstAppModule (is root)][(ses101) MESSAGE_TYPE_RELEASING (2) STATUS_SUCCESS (8) (rp 3)]
[0058](am501) SID = 41 for select sys_context('USERENV', 'SID') as sid from dual
[0060][C][L][r1005][(ctx32) /faces : /firstam-btf/empVoFirstViPage] onAfterDoPoolMessage() : [(am502) SecondAppModule (is root)][(ses101) MESSAGE_TYPE_RELEASING (2) STATUS_SUCCESS (8) (rp 3)]
[0061](am502) SID = 27 for select sys_context('USERENV', 'SID') as sid from dual
Notice the transaction type and DataControl scope information per task-flow.
Notice the different database session SID values ("[0058](am501) SID = 41" and "[0061](am502) SID = 27") during the same request [r1005].
- "maml-log-20130113-jdev111230-nctx.txt" : when using JDeveloper 11.1.2.3.0 and the chained "No Controller Transaction" scenario :
[0002][C][L][r1001][(ctx31) /faces : /firstIndex] logContextInformation() :
[0003]#{a_versionBean.appVersionInfo} = OneSizeOneRootAMApp v0.03 : oracle.jbo.Version = 11.1.2.62.76
Notice the logged information seems similar to when, for the same application and scenario, JDeveloper 11.1.1.6.0 is used (above).
- "maml-log-20130113-jdev111160-tx.txt" : when using JDeveloper 11.1.1.6.0 and the "Always Begin New Transaction and Always Use Existing transaction" scenario :
[0002][C][L][r1001][(ctx31) /faces : /secondIndex] logContextInformation() :
[0003]#{a_versionBean.appVersionInfo} = OneSizeOneRootAMApp v0.03 : oracle.jbo.Version = 11.1.1.61.92
[0013][C][L][r1003][(ctx32) /faces : /secondIndex] onAfterPrepareModel() : task-flow = /WEB-INF/btf/firstam-tx-btf.xml#firstam-tx-btf (no page-fragments)
[0014]transaction type = Always Begin New Transaction, DC scope = isolated DataControlScopeType, DC frame = 1220j2l4q9_5, open transaction = 1220j2l4q9_5, is transaction dirty = false
[0017][C][L][r1003][(ctx32) /faces : /secondIndex] onCreate() : [(am501) FirstAppModule (is root)]
[0018](am501) SID = 41 for select sys_context('USERENV', 'SID') as sid from dual
[0025][C][L][r1003][(ctx32) /faces : /secondIndex] onCreate() : [(am502) onesizeonerootamapp_model_FirstAppModule (not root) parent = [(am501) FirstAppModule (is root)]]
[0026](am502) SID = 41 for select sys_context('USERENV', 'SID') as sid from dual
[0056][C][L][r1005][(ctx32) /faces : /firstam-tx-btf/empVoFirstViPage] onAfterPrepareModel() : task-flow = /WEB-INF/btf/secondam-tx-btf.xml#secondam-tx-btf (no page-fragments)
[0057]transaction type = Always Use Existing Transaction, DC scope = shared DataControlScopeType, DC frame = 1220j2l4q9_5, open transaction = 1220j2l4q9_5, is transaction dirty = true
[0060][C][L][r1005][(ctx32) /faces : /firstam-tx-btf/empVoFirstViPage] onCreate() : [(am503) onesizeonerootamapp_model_SecondAppModule (not root) parent = [(am501) FirstAppModule (is root)]]
[0061](am503) SID = 41 for select sys_context('USERENV', 'SID') as sid from dual
[0063][C][L][r1005][(ctx32) /faces : /firstam-tx-btf/empVoFirstViPage] onAfterDoPoolMessage() : [(am501) FirstAppModule (is root)][(ses101) MESSAGE_TYPE_RELEASING (2) STATUS_SUCCESS (8) (rp 3)]
[0064](am501) SID = 41 for select sys_context('USERENV', 'SID') as sid from dual
Notice that nested Application Module instances are created, resulting in one database session SID value per request.
- "maml-log-20130113-jdev111230-tx.txt" : when using JDeveloper 11.1.2.3.0 and the "Always Begin New Transaction and Always Use Existing transaction" scenario :
[0002][C][L][r1001][(ctx31) /faces : /secondIndex] logContextInformation() :
[0003]#{a_versionBean.appVersionInfo} = OneSizeOneRootAMApp v0.03 : oracle.jbo.Version = 11.1.2.62.76
[0052][C][L][r1005][(ctx32) /faces : /firstam-tx-btf/empVoFirstViPage] onAfterPrepareModel() : task-flow = /WEB-INF/btf/firstam-tx-btf.xml#firstam-tx-btf (no page-fragments)
[0053]transaction type = Always Begin New Transaction, DC scope = isolated DataControlScopeType, DC frame = dw58co387_4, open transaction = dw58co387_4, is transaction dirty = false
[0059][C][L][r1005][(ctx32) /faces : /firstam-tx-btf/empVoFirstViPage] onAfterPrepareModel() : task-flow = /WEB-INF/btf/secondam-tx-btf.xml#secondam-tx-btf (no page-fragments)
[0060]transaction type = Always Use Existing Transaction, DC scope = shared DataControlScopeType, DC frame = dw58co387_4, open transaction = dw58co387_4, is transaction dirty = true
[0070][C][L][r1005][(ctx32) /faces : /firstam-tx-btf/empVoFirstViPage] onAfterDoPoolMessage() : [(am501) FirstAppModule (is root)][(ses101) MESSAGE_TYPE_RELEASING (2) STATUS_SUCCESS (8) (rp 3)]
[0071](am501) SID = 38 for select sys_context('USERENV', 'SID') as sid from dual
[0073][C][L][r1005][(ctx32) /faces : /firstam-tx-btf/empVoFirstViPage] onAfterDoPoolMessage() : [(am502) SecondAppModule (is root)][(ses101) MESSAGE_TYPE_RELEASING (2) STATUS_SUCCESS (8) (rp 3)]
[0074](am502) SID = 38 for select sys_context('USERENV', 'SID') as sid from dual
Notice that two root Application Module instances are used in the same request (and no nested instances), and both (am501) and (am502) report using the same database session SID value. That seems to be "Bruce" [1] at work.
Remember, it should not be difficult (and not intrusive) to configure similar logging for other ADF applications.
- [1] seeblog post "Task flows: Sayonara auto AM nesting in 11.1.2.0.0. Hello, ah, let's call it Bruce."
at http://one-size-doesnt-fit-all.blogspot.com.au/2011/08/task-flows-sayonara-auto-am-nesting-in.html
regards
Jan Vervecken

Creating Root Application Module

Hi,
I'm trying to instantiate a root application module from another root application module,
that imports the first as a library jar file.
In the "Oracle ADF Model and Business Components API Reference" I have found the following sample code:
java.util.Hashtable env = new java.util.Hashtable();
// Add environment entries into env...
javax.naming.Context ic = new InitialContext(env);
String defName = ...;
oracle.jbo.ApplicationModuleHome home = ic.lookup(defName);
oracle.jbo.ApplicationModule am = home.create();
but I don't understand how to initialize the 'env' variable.
Can I have other samples and suggestions?
Arturo

Try something like this:Hashtable prop = new Hashtable();
prop.put(Context.INITIAL_CONTEXT_FACTORY, "com.evermind.server.rmi.RMIInitialContextFactory");
prop.put(Context.PROVIDER_URL, “opmn:ormi://<server>:<container>/<application>”);
prop.put(Context.SECURITY_PRINCIPAL, “user”);
prop.put(Context.SECURITY_CREDENTIALS, “password”);
javax.naming.Context ic = new InitialContext(prop);You have to fill in <server> <container> and <application>.
Timo

Execute SQL after root application module is created

Hi friend
I override this method from Root appModule implementation
protected void afterConnect() {
super.afterConnect();
//I add this line to execute a query when appmodule get db connection
String statement = "ALTER SESSION SET CURRENT_SCHEMA='SCOTT';";
CallableStatement plsqlBlock = getDBTransaction().createCallableStatement(statement, 0);
plsqlBlock.execute();
This is right?, i want to alter schema in db session always.

If it is a session specific initialization, you can try prepareSession() method as explained here.
http://adfcodebits.blogspot.in/2010/06/bit-21-overriding-preparesession-to-do.html
http://docs.oracle.com/cd/B31017_01/web.1013/b25947/bcservices006.htm

Root Application Module issue

We use JDev Build JDEVADF_11.1.1.5.0_GENERIC_110409.0025.6013.
We have a scenario as follows
Model
1. We have a nested AM scenario which contains 2 view instances of the same View Object (EmployeeView) in the nested AM
View
1. URL Invokable Bounded Taskflow containing just one JSPX with transaction set as "Always Begin New Transaction - Not Sharing Data Controls"
2. Bounded Taskflow with JSFF with transaction set as "Use Existing Transaction If Possible - Sharing Data Controls"
3. (2) is dropped as a region in the Page in context of (1)
4. The JSPX page contains a Form intended to display details for EmpId = 105 along with (3)
5. The JSFF referenced in (2) contains another form intended to display details for EmpId = 185
Because, there are 2 different view instances in the RootAM > NestedAM of the same view object EmployeeView,
Expected Behaviour
1. JSPX page should display details for EmpId = 105
2. JSFF Region should display details for EmpId = 185
Noticed Behaviour (Buggy)
Both display details for EmpId = 100 (First Record in the table)
What are we missing here?
Sample demo app. (HR schema) demonstrating the issue
http://www.box.com/s/lr3ervdhnyg696tyoz6d

I can see this working in 11.1.2.1.0. However same failed for the version you mentioned.
Logged a bug#13797593 to track this case. Please follow it up through Oracle Support

Best Practice - Bounded Task Flows, Regions and Nested Application Modules

Using JDev 11.1.1.3; understand that it's generally considered good practice to just have 1 root application module servicing model content / services for each page. In our application, we've used a number of bounded task flows and page fragments deployed as af:region's into pages as either a) views targeted in page-flow navigation, b) tab panel content inside a regular jspx, or c) af:popup / af:dialog content. As it stands, we've not engaged nesting of the application modules for this embedded region content, so these regions are no doubt instantiating new AM's if/when invoked. Should the AM's servicing these embedded regions be deployed nested within the root AM's, and then if so, does this change the way that the jsff / fragment content is actually developed (currently as per any other jspx using the DataControl pallete). Or are the best-practice directives talking about a page as being the design-time / declarative composition of content rather than the run-time aggregation of page + fragments ... in which case the fact that our embedded fragments are not using nested AM's is unlikely to concern.
Thanks,

Probably a better question for the ADF EMG: http://groups.google.com/group/adf-methodology?hl=en
CM.

Making LOV off of an exposed method from second application module

Hello,
I am on JDev 11.1.1.4.0.
My ADF project worked fine until the spec changed on how Lookups are going to be handled. Previuosly, all the lookup tables were in the same database as other tables. Change is that FND Lookups will be created in the "Oracle" and my ADF project should connect to "Oracle" to get appropriate lookup values to build LOVs while maintaining the main database connection intact.
After some research, I now have 2 Application Modules, one my project and the other for Lookups to create LOVs. I went to Application Module configuration wizard to edit JDBC setting to point to "Oracle" database and created a read only view with the following SQL:
SELECT LOOKUP_CODE, MEANING, DESCRIPTION FROM FND_LOOKUP_VALUES
WHERE LOOKUP_TYPE = 'MY_LOOKUP'
AND ENABLED_FLAG = 'Y'
AND LANGUAGE = 'US'I can run both AMs via "Oracle Business Component Browser" fine. However, I somehow have to set the lookup view object as data source to create LOV on the main updatable view object's attribute. If I set it the way I used to do treating the lookup view as a view object residing in the same AM I am getting "table or view does not exist" error. I guess it is something to do with the lookup view object, but I cannot seem to make any kind of progress on this.
Any help would be greatly appreciated.
Thank you
Bones Jones
Edited by: Bones Jones on May 19, 2011 10:40 AM

Well, I think I have found a solution which I didn't have to write a single line of code. My mistake was to think that I have to write code to achieve this.
Here is what I did:
*I already have the main AM and View Objects created for my project. The following steps are done on top of that to bring LOV to life
1. Create a new, pretty empty AM, named LovAM.
1.1 Right click on the newly created AM and select 'Configurations'
1.2 Click JDBC Name value and click 'Edit'
1.3 Select the second database source where Lookup is defined. If not listed, go back out and create a new Database connection and come back.
2. Create a View Object with the following SQL:
SELECT
    TO_NUMBER(LOOKUP_CODE) ID,
    MEANING NAME,
    DESCRIPTION
FROM
    FND_LOOKUP_VALUES
WHERE
    LOOKUP_TYPE = 'MY_LOOKUP' AND ENABLED_FLAG = 'Y' AND LANGUAGE = 'US'3. Notice you now have LovAMDataControl
4. Create a jspx page and create a table with the main data control's binding (This was a part of the requirements).
5. I create a read-only table with LovAMDataControl.LovLookUp1 binding (I think this creates/exposes correct binding in the pageDef).
6. Now I drag-and-drop an attribute that I have been wanting to display LOV from the main binding.
7. Selected single select listbox. You will be presented with 'Edit zlist Binding' screen.
8. Base Data Source is the main data control binding.
9. Select Dynamic List
10. Select LovAM data control binding as List Data Source.
11. (optional) Selected 'Name' as Display Attribute.
11.1. (optional) I don't want to see the table created in step 5. On the jspx page, go to Source tab and delete the table from there. I think this keeps binding in pageDef while the UI component is deleted from the page.
12. Save and Run
Now, I didn't have to create Root Application Module in the code, but still achieved what I wanted.
Thanks
Bones Jones

Nested Application Module - commit behavior

Guys,
I have ADF BC in the following hierarchial manner.
AM1
-VO1
-VO2
-AM2 (nested AM)
Assume that there are pending transactions on both AM1 and AM2.
what is the behaviour for the follwing?
Q1 . Issuing commit on AM1, will it commit AM2 also?
Q2 . Issuing commit on AM2, will it alone commit?
Edited by: Dev on Apr 19, 2011 12:00 PM

ADF distinguish between root application module and nested application modules. A root app module has no parent whereas an nested app module has a parent. A root app module holds the transaction (and only the root app module). Nested app module share the transaction of the root app module (they are nested in).
So Q1: yes and Q2: no.
Read 9.4.2 here http://download.oracle.com/docs/cd/E17904_01/web.1111/b31974/bcservices.htm#sm0229 fro more info.
Timo

Single session for all Application Modules

Hello,
I've got an application that has several Application Modules. All these modules need some data that are set from time to time. I've written some code that calls getSession().getUserData().put("myData",myData). After this method was called in another Application Module i want to retrieve myData with getSession().getUserData().get("myData"). But the result depends if I use 2-tier or 3-tier. In 2-tie I get myData while in 3-tier I get null. My question is:
Is there a Session object or any other data instance that could be accessed from all Application Modules for on application instance.
E.g. I've got two user (A,B) who start my application. Through using my app several instance of Application Modules are created. All Application Modules that are created for the instance of User A should be able to share his user name and some other dynamic data while the Application Modules created for B should have no access to that data.
Doe anybody know if static data of an Application Module are a possible solution?
regards
Joerg

Hi Joerg,
I am not 100% sure what you are trying to achieve, and with which version of JDeveloper/ ADF, technologies (JSP, Swing), etc, but I can tell you that I have been experimenting with single session accounts myself within a rich-client Swing environment, as I have experienced Oracle DBA guys who want to control user authentication via Oracle accounts (I have achieved this via the JCLoginDialog mechanism, and a bit of a hack)... Frank Nemphius (sp?) posted something about a white paper coming out on a related subject but I don't know where he is with that.
Anyway, I managed to do it in a prototype by nesting several application modules within a Root Application Module that was essentially simply a Container for the other application modules. Using this mechanism I was able to bind my root application module to any panel I wanted and it would inherit the roots Session.
ie. I used many application modules and it only used one Oracle Session.
However, my reservations -
1) This solution was not tested robustly!
2) I doubt this would be ideal for a distributed app with thousands of users - My solution is for a very complex app, with a limited number of users.
Finally, I cannot confirm this is a great solution - I can only tell you it worked in my prototype, and I am currently awaiting the ADF source - when my company and Oracle can decide what level of support we currently have and need!?!? - what exactly does being an "Oracle partner" mean??? Its all very boring and un-interesting to a Java person like me... ;-)
Once I have the source I will look at how it actually works and perhaps be able to answer questions like this more definitively. Hmm - I wonder if I could get the Oracle JDBC driver source too?? .... Is it written in C or C++?? I know them too... ;-)
Cheers........Dean

Max no of application modules

Hi all,
In our Jdeveloper application, we have around 18 root application modules (with no nested application modules).
For a new project, we want to build a another model project on top of this application. Is it possible to do so? and if so what are the issues that we should consider?
Also, as i got to know, there is a limitation on maximum no of application modules that an application can have. Can some one pls explain on it?
Thanks in advance,
Surangi

"Will this cause a performance or any other issue that would degrade application quality?"
It depends doesn't it. If you have heaps of CPU & memory and only 1 user, no. If you have millions of user, a 486 and a tape driver for memory, yes.
In essence we have no statistics about your system, and even if we did it would be pretty meaningless to us. As such you should under take load and stress testing to gather statistics and see if the performance is adequate in your specific case.
"And is there a identified number as the optimum number of application modules for one application?"
Again there are no guidelines on this, there is no magic X number. Obviously the more AMs you have the more CPU & memory you will consume. But if you have a low number of users this will be not a problem, and from a development point of view it may just be easier to separate AMs.
CM.

Application Module Nesting Performance

I have multiple application modules and it is currently nested to one main application module.Due to the complexity of my logic, I would like to refactor it further but I cannot move it outside the root application module because the instance of the other services is invoked by
rootAppModule.findApplicationModule("childAppModule"),
If I move it outside the root application module, do we have a performance issue by using createApplicationModule whenever I access the application module?

It's hard to say in general if you'd have a "performance issue", but what I can say is moving it to be its own top-level application module would mean:
-> An extra/different JDBC connection instance
-> An extra/different entity cache
So that might translate into slower performance, but it's always worth doing some benchmarking of exactly what you have in mind to see if for your circumstance the use would incur unwanted overhead or be negligible in the big picture.

One Application Module Instance Per User

Hi, I am using JDeveloper 11.1.1.2 with ADF BC.
I have an application with a single root application module. I have my JDBC data source set up to enable identity based connection pooling so that a database connection is created with the current user's credentials.
Basically, I would like an application module pool such that a single application module instance exists for each user in the system. If a user logs into the system, a new app module should be instantiated for him (tied to his db credentials). If the user makes a new request and his app module has been removed from the pool for inactivity, a new app module should be instantiated even if others already exist in the pool for other users. If the user is already logged into the system and tries to login again in another browser window, I would like to check if an app module already exists in the pool for the user and re-use that one instead of instantiating a new one.
I don't want to set jbo.doconnectionpooling=true because I want the app module instance to keep its cached data.
Is this possible? If so, how could I configure the application module to make this work?

Hi Frank. Thank you for the reply.
I tried using two browsers. The behavior of each page is very much different when being opened individually. Its like the two pages is sharing the same iterator / data and / or entity object. These two pages were opened to see if one is dependent upon the other. But when I test the same scenario on a different computer, everything works out fine.
Is there a way for me to verify if the sessions are different? and if they are different, is there a way to verify if the application module created a new instance for the other session?

ADF BC: Optimal Application Module Runtime Configuration

Have implemented an intranet application for 1000 users using the following technologies implemented on Oracle JDeveloper 10.1.3.0.4:
ADF BC for my Services layer
JSF for my Controller layer
JSF and ADF for my View layer
ADF Model for my Data layer
The application is entirely designed by .jspx and .jsp pages (for reports), handling 106 application modules, with several entity and view objects and without any step-by-step stateful scenario. At each page, there appears a commit button to commit the end-user transaction, and a rollback button to return to the previous page.
The application is database-backed from an Oracle Database 10g, deployed on three application servers Oracle 10.1.3.1 on three different hosts on Suse Linux OS, used data-source connection and AM pooling, and load-balanced by one webcacher in front of the 3 servers.
Under stress test scenario, on a heavy system load in production environment, several ADF State Management errors were recognized that pushed the webacher and application server with the maximum load to automatic restarts due to either demand for JVM increased heap size or errors from the database that the TNS listener complained it could not handle any more connections.
Thus, we started a safety/reliability tess for all our application module components (disabling "Enable application module pooling"), and a stress test using a third-party stress tool at work, but we're still faced with several questions.
(a) What is the best strategy for AM configuration, to quit State Management at all since our application doesn't need it, and if so can it be done globally or declaratively and not individually and programmatically?
(b) Testing on application module runtime configuration, we observed that not to "hang-on" on a connection -default functionality- but to release it at the end of each HTTP request, as each deployment is concentrated on a single data-source connection pool/single user, brought less open JDBC connections on A.S.? Is this the optimal run-time configuration than the default for our case?
(c) If State Management errors are resolved, and using a software balancer before 3 application servers, regulate the traffice by 1/3 to each, is it possible that a system crash will be avoided next time?
So, our problems related to ADF tunning and State Management Errors, but we need a good advice on this topic as the overall documentation is case-specific.

Chapter 29 "Understanding Application Module Pooling" in the ADF Developer's Guide for Forms/4GL Developers on the ADF Learning Center at http://www.oracle.com/technology/products/adf/learnadf.html is the best place to start. There is no "magic" optimal configuration that I (or anyone here, really) can suggest to you. You need to understand the various "knobs and dials" that control the pool sizing and pool cleanup behavior, and then apply application-specific information to this information to derive what the optimal configuration for your particular application will be. The chapter explains how the application module pool and database connection pool interact, and in which situations it is best to change the default setting of the jbo.doconnectionpooling property to true.
Chapter 28 "Application Module State Management" describes the functionality of that facility of the framework, as well as how to release the application module in stateless, unmanaged mode if you need to.
By following the tips in the section "28.3.2.4 Setting Release Level in an Custom ADF PageLifecycle" (which builds on information introduced in section "10.5.4.1 Globally Customizing the ADF Page Lifecycle"), you can generically impose a different release level in your application without "touching" every page.
As a general rule, if you have:
(*) Lots of distinct application modules
(*) Each of which is used as a separate data control (rather than being nested inside a containing application module as described in section "8.9.3 Root Application Modules Versus Nested Application Module Usages" of the dev guide)
(*) Each of which uses the same database connection
Then as described in section "29.8 How Database and Application Module Pools Cooperate" in the guide, your application can decrease the total overall number of connections used by using the non-default setting of jbo.doconnectionpooling=true.
Applications using many distinct data controls in the span of a single user's session need to be aware of Bug# 4566186 ("PERF: ADFBINDINGFILTER CHECKS OUT ALL ADF BC DATA CONTROLS USED AT LEAST ONCE"). This issue has been fixed in JDev/ADF 11g, but apparently the fix was too complex to accommodate a 10.1.X backport. I'm trying to document a workaround and publish it on my blog, but I'm not finished with it yet.

Root Application Module

Similar Messages

Maybe you are looking for