-
Notifications
You must be signed in to change notification settings - Fork 154
JDBC pools configuration
BTM XA datasources can be created via some java code or via a BTM-specific tool called the Resource Loader. You are free to choose the method you prefer, there is absolutely no difference between them.
The name of the JDBC driver's XADataSource implementation class.
Each datasource must be assigned a unique name. This is required for distributed crash recovery.
The minimum number of active connections the pool will try to keep in the pool. In an idle system, the number of active connections will trend toward this value until it is reached. Connections that are retired and bring the pool below this value will be replenished until this minimum pool size is reached. Default value: 0.
The maximum number of active connections the pool will allow in the pool. If this maximum is reached, a request for a connection from the pool will block the calling thread until a connection is available or the acquisitionTimeout is reached. This value should be overridden. Default value: 0.
When the pool is above the minPoolSize, this parameter controls how long (in seconds) an idle connection will stay in the pool before being retired. However, even if a connection is idle for longer than maxIdleTime, the connection will not be retired if it would bring the pool below the minPoolSize. Default value: 60.
This parameter controls how long (in seconds) a connection is allowed to live in the pool regardless of the minPoolSize parameter value. If a connection exceeds this time, and it is not in use, it will be retired from the pool. If the retirement of a connection causes the pool to dip below the minPoolSize, it will be immediately replaced with a new connection. This setting can be used to avoid unexpected disconnect due to database-side connection timeout. It is also useful to avoid leaks and release resources held on the database-side for open connections. Default value: 0.
This parameter controls how many connections are filled into the pool when the pool is empty but the maxPoolSize has not been reached. If there aren't enough connections in the pool to fulfill a request, new connections will be created, by increments of acquireIncrement at a time. Default value: 1.
This parameter controls how long (in seconds) a request for a connection from the pool will block before being aborted (and an exception thrown). Default value: 30.
This parameter controls how long (in seconds) the pool waits between attempts to create new connections. This time in included within in the acquisitionTimeout. Default value: 1.
By default, whenever a thread requests a connection from the DataSource, BTM will issue a new connection. All connections issued are bound into the same transaction context. Depending on the design of the user's application, this behavior can result in a large number of connections to the database -- and in the case of a database such as PostgreSQL, which uses one process per-connection this places a fairly heavy burden on the database. Setting this option to true will enable a thread-associated connection cache. With this option enabled, no matter how many times a thread requests a connection from the DataSource, BTM will return a single connection. Because connections can be shared within the context of a transaction, this provides a more efficient use of connection resources. A positive benefit of a single connection per thread is that the prepared statement cache (which is per-connection) is also made more efficient. Lastly, another benefit is that because connections are shared within the same thread, the overhead of establishing and testing a new connection to the database is avoided, which significantly improves the performance of some access patterns. Of course, BTM will still ensure correctness whenever this parameter is set to true. While the default value of this property is false for backward compatibility, the recommended setting is true. Default value: false.