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.
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:
1. JTDataSource.properties
2. FakeXADataSource.properties
The JTDataSource.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/FakeXADataSource.properties
loggingSQLError=false
Important: 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, 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 FakeXADataSource.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
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.
For Connecting to MySQL :
driver=com.mysql.jdbc.jdbc2.optional.MysqlXADataSource
URL=jdbc:mysql://localhost:3306
For Connecting to Oracle :
driver=oracle.jdbc.OracleDriver
URL=jdbc:oracle:thin:@localhost:1521
Note: Depends on the Oracle DB version driver may change. Use the driver as per the respective version
