Using the Administration Interface
Using the Command-Line Interface
To create a new JDBC connection pool using the Administration interface, do the following
Access the Server Manager and choose the Java tab.
Click JDBC Connection Pools.
From the Database Vendor drop down, select the type of database that you want to connect to. If your DBMS is not listed, select Other.
The Add New JDBC Connection Pool page is displayed.
Specify the properties for your new connection pool and click OK.
Listed below are the connection pool properties that you must specify:
DataSource Classname: The vendor-specific classname that implements the data source. If you selected Other from the Database Vendor list in the New JDBC Connection Pool page, you must enter the vendor-specific classname of the data source you plan to use. Please note that this class must implement javax.sql.DataSource.
Specify standard and proprietary JDBC connection pool properties. Many of these properties are optional. By default the names of all of the standard properties are provided. You will need to consult your database vendor’s documentation to determine the standard and vendor specific properties that are required.
Steady Pool Size: Specify the minimum number of connections that the pool should maintain. When a connection is given to a requesting thread, it is removed from the pool, reducing the current pool size. The steady pool size also refers to the number of connections that will be added to the pool on server startup.
Pool Resize Quantity: When the pool shrinks toward the steady pool size it is resized in batches. This value determines the size of the batch. Making this value too large will delay connection recycling, making it too small will be less efficient.
The pool capacity is only ever increased one connection at a time so this field does not effect increases in pool capacity.
Max Wait Time (milli secs): The amount of time the caller will wait before getting a connection timeout. The default wait time is long, which means that a caller can wait for a long time. If this value is set to 0, the caller will be blocked until a connection is available.
Connection Validation Required: If this field is checked connections are validated before they are passed to the application. This allows the web server to automatically re-establish database connections in the case of the database becoming unavailable due to network failure or database server crash. Validation of connections cause additional overhead and slightly reduce performance.
auto-commit: In this mode, query statements are executed and committed as individual transactions. When auto-commit is disabled, query statements are grouped into transactions that can be terminated by either commit or roll back mechanisms.
meta-data: In this mode, a connection’s database is able to provide meta-information describing its tables, its stored procedures, and so on. Each instance of the meta-data object will have a particular query associated with it. The meta-data object will execute that query and cache the results.
Fail All Connections: Specifies whether to fail all connections in the pool and re-establish them if a single connection is determined to have failed. If left unchecked, connections will be individually re-established only when they are used.
The isolation level that a transaction uses determines how sensitive the application is to changes that other users’ transactions make, and consequently, how long the transaction must hold locks to protect against these changes.
Transaction Isolation. Allows you to select the transaction isolation level for this connection. Choose from the following values:
read-committed. This places shared locks on data in such a way that data another transaction has changed but not yet committed will never be read. Because uncommitted data is not read, if a transaction running with read-committed isolation queries the data again, that data might have changed, or additional data might appear that meet the criteria of the original query.
repeatable-read. This ensures that locks will be placed on all data that is used in a query. No other user can modify the data that your transaction visits as long as you have not yet committed or rolled back your transaction.
serializable. This locks ranges of data so that if a query is reissued, no data will have changed and no additional rows of data will appear during the time interval between the first and second query.
Guarantee Isolation Level. This ensures that any connection taken from the pool will have the same isolation level. For example, if the isolation level for the connection was changed programatically (for example, con.setTransactionIsolation) when last used, this mechanism will change it back to the specified isolation level.