You can set up and configure a connection pool manually by creating two files in your localconfig/atg/dynamo/service/jdbc/ directory:

where connectionPoolName is the name of the connection pool you want to create.

The file contains properties and values similar to the following:


The min property determines the number of connections that the pool starts out with. The max property determines how many connections are to be kept around in the pool. When the pool starts, it immediately creates the minimum number of connections. Whenever a service requires a connection, it takes one from the pool. If there are no connections free, then the connection pool creates a new connection, until the maximum is reached. Due to various initialization calls, Dynamo requires at least three JDBC connections on install or when started with a new database. Setting the JDBC connection pool’s max property to anything less causes Dynamo to hang when starting up.

If the maximum has been reached and a service requires another connection, then the service blocks until some other service frees up a connection. If the blocking property is set to false, then instead of blocking, the connection pool fails and results in a SQL exception.

The file contains properties and values similar to the following:


These properties tell the connection pool how to make a connection. The driver parameter specifies the name of the driver that should be used. The URL property specifies the name of the database server machine, the port of the database server (optional), and the name of the database on the server (optional). The format of the URL looks like this:

jdbc:driver name[:additional server information]

By default, the connection pool’s driver and URL are configured for the SOLID database, as follows:


The user and password properties provide the connection with login access to the database, and must be recognized by the target database.

The readOnly property determines whether the resulting connection will only be used to perform read-only operations. Some drivers may be able to improve performance if this is true. Most applications require read and write access, so this property is usually false.

Dynamo wraps the Connection object to separate out SQL warning and info messages (see Monitoring Connection Activity). This lets you see the SQL statements generated by Dynamo. It also catches SQLExceptions that occur on the connection and causes the connection to be closed when it is checked by into the resource pool. In addition to the standard ApplicationLogging log levels (loggingError, loggingWarning, loggingInfo and loggingDebug), a monitored connection lets you split off the SQL log messages with these properties:




logs SQL exceptions as errors


logs SQL warnings received by the pool


logs SQL statements sent by the pool


logs JDBC method calls made by the pool

By default, Dynamo turns SQL warnings off since they tend to be informational messages, not warnings. If you want to log these messages, set loggingSQLWarning to true.

loading table of contents...