ATG uses its own data sources when running data import scripts. These scripts are used for initial application configuration. The data source is based on /atg/dynamo/service/jdbc/JTDataSource, a Nucleus service that creates new connections to a particular database.
Your running ATG application will use your application server’s native data sources (see Configuring Data Sources and Transaction Management in this guide).
J2EE JDBC supports the Java Transaction API (JTA) via the javax.sql.XADataSource interface. JTA allows multiple resources from different providers to participate in the same transaction. Using two-phase commits, data integrity across different services is ensured. ATG supplies a DataSource that sits on top of an XADataSource and returns wrapped Connections that are registered appropriately with the associated Transaction Manager. ATG’s DataSource must get all its Connections from an XADataSource. Only a true XADataSource produces connections that behave properly in a two-phase commit controlled by JTA. XADataSources should be included in JDBC 2.0 drivers for the various database vendors.
The default DataSource connection pool, JTDataSource, uses the FakeXADataSource component, which is configured by default for the SOLID database. If you want to use a database other than SOLID, you must configure the desired connection pool properties, but note that this datasource should be used only to run ATG data import scripts.
You can set up and configure a connection pool manually by creating two files in your localconfig/atg/dynamo/service/jdbc/ directory:
connectionPoolName.propertiesconnectionPoolNameFakeXA.properties
where connectionPoolName is the name of the connection pool you want to create.
The connectionPoolName.properties file contains properties and values similar to the following:
$class=atg.service.jdbc.MonitoredDataSource
min=10
max=10
blocking=true
maxFree=-1
loggingSQLWarning=false
loggingSQLDebug=false
loggingSQLInfo=false
dataSource=/atg/dynamo/service/jdbc/<connectionPoolName>FakeXA
loggingSQLError=falseThe 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, ATG 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 ATG 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 connectionPoolNameFakeXA.properties file contains properties and values similar to the following:
$class=atg.service.jdbc.FakeXADataSource server=localhost:1313 user=admin needsSeparateUserInfo=false URL=jdbc:solid://localhost:1313 readOnly=false password=admin database= driver=solid.jdbc.SolidDriver
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:
driver=solid.jdbc.SolidDriver
URL=jdbc:solid://localhost:1313
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.
ATG wraps the Connection object to separate out SQL warning and info messages. This lets you see the SQL statements generated by ATG. 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:
Property | Description |
|---|---|
| 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, ATG turns SQL warnings off since they tend to be informational messages, not warnings. If you want to log these messages, set loggingSQLWarning to true.
