-
Notifications
You must be signed in to change notification settings - Fork 151
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.
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) the pool waits between attempts to create new connections. This time in included within in the acquisitionTimeout. 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 is used to adjust whether or not you want to be able to run SQL statements outside of XA transactions scope. Defaults value: false.
Should the transaction timeout be passed to the resource via XAResource.setTransactionTimeout()? Default value: false.
This parameter controls whether connections from the PoolingDataSource are automatically enlisted/delisted into the XA transactions. If this is set to false then have to enlist XAResource objects manually into the Transaction objects for them to participate in XA transactions. Default value: true.
The name of the JDBC driver's XADataSource implementation class.
Set this parameter to false if the vendor's XADataSource implementation supports transactions interleaving. Default value: false
This parameter controls whether this DataSource configuration is disabled or enabled. Default value: false.
If your JDBC driver supports JDBC4, this method of testing the connection is likely much more efficient than using the testQuery parameter. In the case of a testQuery, the query must be sent to the DB server, parsed, and executed before the connection can be used. JDBC4 exposes a method by which a driver can make its own determination of connectivity (possibly whether the socket is still connected, etc.). Default value: false.
Should recovery errors be ignored? Ignoring recovery errors jeopardizes the failed transactions atomicity so only set this parameter to true when you know what you're doing. This is mostly useful in a development environment. Default value: false.
Set the default isolation level. All of the four standard READ_COMMITTED, READ_UNCOMMITTED, REPEATABLE_READ and SERIALIZABLE values are supported. Default value: READ_COMMITTED
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.
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.
Controls how many Prepared Statements are cached (per connection) by BTM. A value of 0 means that statement caching is disabled. Default value: 0.
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.
This parameters sets the SQL statement that is used to test whether a connection is still alive before returning it from the connection pool.
This parameter controls the position of this resource during the 2PC protocol execution. This is required if you want to guarantee that a resource commits before another one. Default value: 0.
Each datasource must be assigned a unique name. This is required for distributed crash recovery.
Set this parameter to false if the vendor's XADataSource implementation does not implement XAResource.isSameRM() properly. Refer to the JdbcXaSupportEvaluation page to see if your database needs it. Default value: true.