|
AM Pooling Considerations for ADF JClient
A customer wrote in recently saying:
In your ADF Business Components Performance Tips and Tricks Web Seminar you mentioned that ADF BC always uses JDBC connection pooling behind the scenes. If I set jbo.doconnectionpooling to false in the application module configuration, is it still doing connection pooling? If it makes a difference, I'm using JClient not a Web application.
The executive summary is that jbo.doconnectionpooling is an unfortunate name for the parameter, since we actually do perform connection pooling whether the value is true or false. The value does change the behavior of how the database connection pool is used, and it is possible to completely disable connection pooling if you want. I try to answer these questions in this brief article.
If you are using JDBC DataSources, then ADF BC does not control the connection pooling behavior, your J2EE container does.
Assuming you're using JDBC URL connections, it always uses connection pooling, unless you set the maximum JDBC connection pool size to 0, in which case it performs no JDBC connection pooling. The DB connection pool has it's own set of tuning parameters that govern when instances are removed from the pool. It's basically a function of the DB pool monitor interval, the DB pool idle time, and the minimum available size. When the DB pool monitor wakes up, if it finds DB connections that have been idle longer than the DB pool idle time, then it will remove them unless removing them would bring the instances in the pool to a number lower than the DB pool minimum available size. If removing the idle connection would bring the connection instances in the DB pool below its minimum available size, then it leaves them in the pool to respect that setting.
The difference that jbo.doconnectionpooling controls is whether the JDBC connection stays with the AM instance in the AM pool (jbo.doconnectionpooling=false), or is released back to the JDBC connection pool (jbo.doconnectionpooling=true), upon checking in the application module to the pool in an unmanaged way. Since the JClient layer checks out an AM and keeps it for the life of the JUApplication session until checking it back in in an unmanaged way at the end, the setting of jbo.doconnectionpooling is really not relevant since the AM will only be put back in the pool when the panelBinding.
JClient uses an AM Pool on the client side. Unless you're opening several instances of the same form, you likely never have more than one instance of any given root AM in its client-side, per-root-ApplicationModule pool.
In 9.0.3/9.0.4-style JClient code, when you call release() on your JUApplication object, the AM instance is removed from the pool. Internally, JUApplication is using Configuration.createRootApplicationModule() and Configuration.releaseRootApplicationModule(.,true) as can be seen by reviewing the JUApplication source code. Since it passes true to this latter method, the AM is cleaned up immediately and its DB connection will be returned to the database connection pool. The DB connection will be cleaned up eventually when its idle time has elapsed and the DB pool monitor notices this, provided that the setting of the DB pool's minimum available size allows it to be cleaned up. This 9.0.3/9.0.4 approach for AM use is slightly different from the way that 9.0.5/10.1.2 ADF JClient uses the AM pool.
In 9.0.5/10.1.2 ADF JClient, when the JClient code calls panelBinding.releaseDataControl() it will cause the session cookie to timeout immediately and that will release the AM back to the pool. In this 9.0.5/10.1.2 case, at that point, the "idle" time will begin to accumulate for that AM instance, assuming you don't use it again by having the user launch another form that uses it. When the AM pool monitor wakes up (by default, every 10 minutes (= 600 sec = 60000 msecs) it will look for any AM instances that have been idle longer than their idle timeout (by default, 10 minutes). If any idle AM's are found that qualify, it will look at the minimum available size (by default, 5) and will stop if freeing the idle AM's would bring the pool below the minimum available size.
So, if you don't do any tuning, the AM that is released to the pool will actually never get cleaned up (until the client process exits) because even after two 10-minute pool monitor wakeup cycles, where on the 2nd wakeup for sure the AM instance will have been idle at least 10 minutes (the idle time), the one instance in the pool will not get cleaned up since the pool won't shrink below the minimum available instances (of 5, by default).
So in 9.0.5/10.1.2, do get the AM cleaned up you have the following two options:
- Set the AM pool's minimum available size to 0 (zero), and set the idle time and pool monitor interval shorter if the up-to 20-minute wait (in case it takes two wakeup cycles for the AM instance to be idle more than its idle time) is not something you like, or
- Disable AM pooling altogether (jbo.ampooling.doampooling=false)
At that point, the DB connection will be cleaned up eventually when its idle time has elapsed and the DB pool monitor notices this, provided that the setting of the DB pool's minimum available size allows it to be cleaned up.
You can refer to this OTN whitepaper for info on all the pooling parameters.
In the future, we're planning to enable JClient to use a server-side AM pool like web clients use but that's not there yet in10.1.2.
|
