This content has been marked as final. Show 9 replies
Can you provide a bit more info:
- what is the (nested) structure of your application modules?
- in which application module did you define the view object usage used by the LOV group?
- what is the value of the Data Collection property in the LOV group?
I have a single application module (no nested app modules inside). The view object usage for both the lov group and the main group are defined in this same application module.
The value of the Data Collection property in the LOV group is the name of the View Object instance for example RegionsLookup.
The first time i open the lov a new db connection is opened up. Also every time i open the lov, the method prepareSession of the ApplicationModule is called. This behaviour happens in
every application where the jhs lovs are used but not when i use model-inputTextLovs.
This is standard ADF BC behavior. JHeadstart LOV's are simply using a VO instance. On each request prepareSession is called, just like on VO instances not used for LOV's.
Build a sample app without JHeadstart and you will see the same behavior.
This standard ADF BC behavior you are referring to, is happening only when you set the jbo.doconnectionpooling to true which means that application module is disconnected upon release. However this is not the case in our applications where we are using the default application module configurations, where optimally the application module is session scoped (prepareSession method is called only once for each session).
I am not really sure but i think that opening a new database connection has to do with the fact that all jhs-lovs are bounded task flows and the task flow's transaction option is set to <No Controller Transaction> instead of Always Use Existing Transaction option.
I really wonder, am i the only one who encounters this behaviour about jhs-lovs?
if no controller transaction is specified (which by default is the case when using JHeadstart), the data control scope setting determines whether a new AM instance and associated DB connection is created. The default data control scope is "shared". Maybe you cnahged the data control scope setting at the application level, or for individual LOV groups?
That would explain the behavior you are seeing.
I use the default configuration. Does it have to do that the development platform is linux, I doubt about it. In 5 applications using jheadstart 126.96.36.199.35 and jdeveloper 188.8.131.52.0, we encounter the same behaviour:
When we open a jhs lov for the first time a new connection spans. Then this connection is reused for any subsequent jhs lov calls.
So for every root application module with jhs lovs we always have 2 db connections (when we query v$session) instead of 1, so 5 root ams with jhs lovs will span 10 db connections.
I tried to change the transaction option to Always Use Existing Transaction but then a runtime exception is thrown:
Caused by: oracle.adf.controller.activity.ActivityLogicException: ADFC-00006: Existing transaction is required when calling task flow '/WEB-INF/adfc-config-EmployeesLookupn.xml#EmployeesLookupnTaskFlow'.
Also the "share data controls with calling task flow" option for the individual Lov is always checked by default. How can i change the data scope setting at the application level?
I can send you a small test case i created to see for yourself.
yes, please send the testcase to email@example.com
OK, found it.
The lov taskflow template includes
This means that for every LOV a new AM instance will be created. The reason we set the data control scope to isolated is that it allows updateable LOV's, where a new row is inserted independent of the pending base page transaction.
So, if your LOV's are read-Only, you can customize the lov taskflow template and remove the isloated data control scope. It would be better to have this as the default, as most LOV's are readOnly, so we will change this for the next release.
Yes, that solves everything!!!