user manual

Chapter 27: Using VisiConnect 291
Connection Management
You configure this setting using the maximum-capacity element in the ra-
borland.xml descriptor file. If a new Managed Connection (or more than one
Managed Connection in the case of capacity-delta being greater than one)
needs to be created during a connection request, Borland Enterprise Server
ensures that no more than the maximum number of allowed Managed
Connections are created. If the maximum number is reached, Borland
Enterprise Server attempts to recycle a Managed Connection from the
connection pool. However, if there are no connections to recycle, a warning is
logged indicating that the attempt to recycle failed and that the connection
request can only be granted for the amount of connections up to the allowed
maximum amount. The default value for maximum-capacity is 10 Managed
Connections.
Controlling System Resource Usage
Although setting the maximum number of Managed Connections prevents the
server from becoming overloaded by more allocated Managed Connections
than it can handle, it does not control the efficient amount of system resources
needed at any given time. Borland Enterprise Server provides a service that
monitors the activity of Managed Connections in the connection pool during
the deployment of a resource adapter. If the usage decreases and remains at
this level over a period of time, the size of the connection pool is reduced to an
efficient amount necessary to adequately satisfy ongoing connection requests.
This system resource usage service is turned on by default. However, to turn
off this service, you can set the cleanup-enabled element in the ra-borland.xml
descriptor file to false. Use the cleanup-delta element in the ra-borland.xml
descriptor file to set the frequency with which Borland Enterprise Server
calculates the need for connection pool size reduction, and if reduction is
needed, selectively removes unused Managed Connections from the pool.
The default value of this element is 15 minutes.
Detecting Connection Leaks
Connection leaks result from faulty application components, such as an
Enterprise JavaBean (EJB), not doing their job to close a connection after
using them. As stated in the Connectors 1.0 specification, once the application
component has completed its use of the EIS connection, it sends a close
connection request. At this point, VisiConnect is responsible for any necessary
cleanup and making the connection available for a future connection request.
However, if the application component fails to close the connection, the
connection pool can be exhausted of its available connections, and future
connection requests can therefore fail.
VisiConnect provides two mechanisms for preventing this scenario:
■
Leveraging a garbage collector
■
Providing an idle timer for tracking the usage of connection objects