If
your application contains many application modules (let's say 50) and
there are lots of concurrent users working at the same time, with
default ADF BC settings we would reserve large number of database
connections. Reserved connection will be hanging until AM instance
will be destroyed. This is not what we want, especially with high
number of concurrent users. If we set jbo.doconnectionpooling = true,
database connection will be reserved only during HTTP request and
then released. That's not good, because lots of AM
passivation/activation will happen. However, with second property -
jbo.txn.disconnect_level = 1, ADF BC instead of
passivating/activating to database, will keep AM data in memory
during HTTP requests. It will passivate/activate as expected, only if
AM instance will be granted to another session (situation when no
free AM instances in the pool).
Select your Application Module and then go to configuration then edit local one
Disconnect Application Module Upon Release
Forces the application module pool to release the JDBC connection used each time the application module is released to the pool. See Section 41.2.6, "What You May Need to Know About How Database and Application Module Pools Cooperate" for more information.
mark check for Disconnect Application Module Upon Release
In properties Tab of the above mentioned configuration window. (jbo.doconnectionpooling) and jbo.txn.disconnect_level .
jbo.doconnectionpooling feature is disabled by default (false).
there is option to tune data source usage in ADF by setting jbo.doconnectionpooling = true
and jbo.txn.disconnect_level = 1.
and jbo.txn.disconnect_level = 1.
set
jbo.txn.disconnect_level=1 (default is 0) to
ensure that all application modules, view objects and row sets remain
in memory and stay valid after their corresponding references to JDBC
connections are dropped. Upon activation, the framework re-executes
and synchronizes the cursor positions. When used in conjunction with
jbo.doconnectionpooling=true,
setting jbo.txn.disconnect_level=1 reduces the memory overhead
associated with this situation.
NOTE: Leave the jbo.doconnectionpooling configuration parameter set to false for best performance without sacrificing scalability and reliability. Database connection pooling is still achieved through application module pooling. The only exception is when multiple application module pools (and therefore a large number of application module instances) share the same database, making the total available database connections the highest priority
For
more details, refer to these 2 links which i have found very helpful:
