29.6 Application Module Pool Parameters

The application module pool configuration parameters fall into three logical categories relating to pool behavior, pool sizing, and pool cleanup behavior.

29.6.1 Pool Behavior Parameters

Table 29-2 lists the application module configuration parameters that affect the behavior of the application module pool.

Table 29-1 Application Module Pool Behavior Configuration Parameters

Pool Configuration Parameter Description

Pool Configuration Parameter	Description
Failover Transaction State Upon Managed Release (`jbo.dofailover`)	Enables eager passivation of pending transaction state each time an application module is released to the pool in "Managed State" mode. See Section 28.2.3, "How Passivation Changes When Optional Failover Mode is Enabled" for more information. This feature is disabled by default (`false`)
Disconnect Application Module Upon Release (`jbo.doconnectionpooling`)	Forces the application module pool to release the JDBC connection used each time the application module is released to the pool. See Section 29.8, "How Database and Application Module Pools Cooperate" for more information. This feature is disabled by default (`false`).
Support Dynamic JDBC Credentials (`jbo.ampool.dynamicjdbccredentials`)	Enables additional pooling lifecycle events to allow developer-written code to change the database credentials (username/password) each time a new user session begins to use the application module. This feature is enabled by default (`true`), however this setting is a necessary but not sufficient condition to implement the feature. The complete implementation requires additional developer-written code.
Reset Non-Transactional State Upon Unmanaged Release (`jbo.ampool.resetnontransactionalstate)`)	Forces the application module to reset any non-transactional state like view object runtime settings, JDBC prepared statements, bind variable values, etc. when the application module is released to the pool in unmanaged or "stateless" mode. This feature is enabled by default (`true`). Disabling this feature can improve performance, however since it does not clear bind variable values, your application needs to ensure that it systemically sets bind variable values correctly. Failure to do so with this feature disabled can mean one user might see data with another users bind variable values.)
Enable Application Module Pooling (`jbo.ampool.timetolive`)	Enables the application module pooling facility. See Section 28.8, "Testing to Ensure Your Application Module is Activation-Safe" for more information on when Oracle recommends to disable this feature as a routine part of your application testing. This feature is enabled by default (`true`)

Failover Transaction State Upon Managed Release

(jbo.dofailover)

Enables eager passivation of pending transaction state each time an application module is released to the pool in "Managed State" mode. See Section 28.2.3, "How Passivation Changes When Optional Failover Mode is Enabled" for more information.

This feature is disabled by default (false)

Disconnect Application Module Upon Release

(jbo.doconnectionpooling)

Forces the application module pool to release the JDBC connection used each time the application module is released to the pool. See Section 29.8, "How Database and Application Module Pools Cooperate" for more information.

This feature is disabled by default (false).

Support Dynamic JDBC Credentials

(jbo.ampool.dynamicjdbccredentials)

Enables additional pooling lifecycle events to allow developer-written code to change the database credentials (username/password) each time a new user session begins to use the application module.

This feature is enabled by default (true), however this setting is a necessary but not sufficient condition to implement the feature. The complete implementation requires additional developer-written code.

Reset Non-Transactional State Upon Unmanaged Release

(jbo.ampool.resetnontransactionalstate))

Forces the application module to reset any non-transactional state like view object runtime settings, JDBC prepared statements, bind variable values, etc. when the application module is released to the pool in unmanaged or "stateless" mode.

This feature is enabled by default (true). Disabling this feature can improve performance, however since it does not clear bind variable values, your application needs to ensure that it systemically sets bind variable values correctly. Failure to do so with this feature disabled can mean one user might see data with another users bind variable values.)

Enable Application Module Pooling

(jbo.ampool.timetolive)

Enables the application module pooling facility. See Section 28.8, "Testing to Ensure Your Application Module is Activation-Safe" for more information on when Oracle recommends to disable this feature as a routine part of your application testing.

This feature is enabled by default (true)

29.6.2 Pool Sizing Parameters

Table 29-2 lists the application module configuration parameters that affect the sizing of the application module pool.

Table 29-2 Application Module Pool Sizing Configuration Parameters

Pool Configuration Parameter Description

Pool Configuration Parameter	Description
Initial Pool Size (`jbo.ampool.initpoolsize`)	The number of application module instances to created when the pool is initialized. The default is `0` (zero) instances.
Maximum Pool Size (`jbo.ampool.maxpoolsize`)	The maximum number of application module instances that the pool can allocate. The pool will never create more application module instances than this limit imposes. The default is `5000` instances.
Referenced Pool Size (`jbo.recyclethreshold`)	The maximum number of application module instances in the pool that attempt to preserve session affinity for the next request made by the session which used them last before releasing them to the pool in managed-state mode. The referenced pool size should always be less than or equal to the maximum pool size. The default is to allow `10` available instances to try and remain "loyal" to the affinity they have with the most recent session that released them in managed state mode.
Maximum Instance Time to Live (`jbo.ampool.timetolive`)	The number of milliseconds after which to consider an application module instance in the pool as a candidate for removal during the next resource cleanup regardless of whether it would bring the number of instances in the pool below minavailablesize. The default is 3600000 milliseconds of total time to live (which is 3600 seconds, or one hour)

Initial Pool Size

(jbo.ampool.initpoolsize)

The number of application module instances to created when the pool is initialized.

The default is 0 (zero) instances.

Maximum Pool Size

(jbo.ampool.maxpoolsize)

The maximum number of application module instances that the pool can allocate.

The pool will never create more application module instances than this limit imposes. The default is 5000 instances.

Referenced Pool Size

(jbo.recyclethreshold)

The maximum number of application module instances in the pool that attempt to preserve session affinity for the next request made by the session which used them last before releasing them to the pool in managed-state mode.

The referenced pool size should always be less than or equal to the maximum pool size. The default is to allow 10 available instances to try and remain "loyal" to the affinity they have with the most recent session that released them in managed state mode.

Maximum Instance Time to Live

(jbo.ampool.timetolive)

The number of milliseconds after which to consider an application module instance in the pool as a candidate for removal during the next resource cleanup regardless of whether it would bring the number of instances in the pool below minavailablesize.

The default is 3600000 milliseconds of total time to live (which is 3600 seconds, or one hour)

29.6.3 Pool Cleanup Parameters

A single "application module pool monitor" per Java VM runs in a background thread and wakes up every so often to do resource reclamation. Table 29-3 lists the parameters that affect how resources are reclaimed when the pool monitor does one of its resource cleanup passes.

Note:

Since there is only a single application monitor pool monitor per Java VM, the value that will effectively be used for the application module pool monitor polling interval will be the value found in the application module configuration read by the first application module pool that gets created. To make sure this value is set in a predictable way, it is best practice to set all application modules to use the same Pool Polling Interval value.

Table 29-3 Application Module Resource Management Configuration Parameters

Pool Configuration Parameter Description

Pool Configuration Parameter	Description
Pool Polling Interval (`jbo.ampool.monitorsleepinterval`)	The length of time in milliseconds between pool resource cleanup. While the number of application module instances in the pool will never exceed the maximum pool size, available instances which are candidates for getting removed from the pool do not get "cleaned up" until the next time the application module pool monitor wakes up to do its job. The default is to have the application module pool monitor wake up every `600000` milliseconds (which is 600 seconds, or ten minutes).
Maximum Available Size (`jbo.ampool.maxavailablesize`)	The ideal maximum number of application module instances in the pool when not under abnormal load. When the pool monitor wakes up to do resource cleanup, it will try to remove available application module instances to bring the total number of available instances down to this ideal maximum. Instances that have been not been used for a period longer than the idle instance time-out will always get cleaned up at this time, then additional available instances will be removed if necessary to bring the number of available instances down to this size. The default maximum available size is `25` instances.
Minimum Available Size (`jbo.ampool.minavailablesize`)	The minimum number of available application module instances that the pool monitor should leave in the pool during a resource cleanup operation. Set to zero (`0`) if you want the pool to shrink to contain no instances when all instances have been idle for longer than the idle time-out. The default is `5` instances.
Idle Instance Timeout (`jbo.ampool.maxinactiveage`)	The number of milliseconds after which to consider an inactive application module instance in the pool as a candidate for removal during the next resource cleanup. The default is 600000 milliseconds of idle time (which is 600 seconds, or ten minutes).
Maximum Instance Time to Live (`jbo.pooltimetolive`)	The number of milliseconds after which to consider an connection instance in the pool as a candidate for removal during the next resource cleanup regardless of whether it would bring the number of instances in the pool below minavailablesize. The default is 3600000 milliseconds of total time to live (which is 3600 seconds, or one hour)

Pool Polling Interval

(jbo.ampool.monitorsleepinterval)

The length of time in milliseconds between pool resource cleanup.

While the number of application module instances in the pool will never exceed the maximum pool size, available instances which are candidates for getting removed from the pool do not get "cleaned up" until the next time the application module pool monitor wakes up to do its job. The default is to have the application module pool monitor wake up every 600000 milliseconds (which is 600 seconds, or ten minutes).

Maximum Available Size

(jbo.ampool.maxavailablesize)

The ideal maximum number of application module instances in the pool when not under abnormal load.

When the pool monitor wakes up to do resource cleanup, it will try to remove available application module instances to bring the total number of available instances down to this ideal maximum. Instances that have been not been used for a period longer than the idle instance time-out will always get cleaned up at this time, then additional available instances will be removed if necessary to bring the number of available instances down to this size. The default maximum available size is 25 instances.

Minimum Available Size

(jbo.ampool.minavailablesize)

The minimum number of available application module instances that the pool monitor should leave in the pool during a resource cleanup operation. Set to zero (0) if you want the pool to shrink to contain no instances when all instances have been idle for longer than the idle time-out.

The default is 5 instances.

Idle Instance Timeout

(jbo.ampool.maxinactiveage)

The number of milliseconds after which to consider an inactive application module instance in the pool as a candidate for removal during the next resource cleanup.

The default is 600000 milliseconds of idle time (which is 600 seconds, or ten minutes).

Maximum Instance Time to Live

(jbo.pooltimetolive)

The number of milliseconds after which to consider an connection instance in the pool as a candidate for removal during the next resource cleanup regardless of whether it would bring the number of instances in the pool below minavailablesize.

The default is 3600000 milliseconds of total time to live (which is 3600 seconds, or one hour)