Database handles

A database handle is the name attribute that was used in the <database> tag of the schema.xml file. If the name attribute is not used, then the handle would be 'default'.

In all examples that follow we will use the handle 'bookstore'. As Torque has the ability to use multiple databases you can tell it which one to use by default thus:

torque.database.default=bookstore

The handle name 'default' is reserved, as Torque uses it as a reference to the default database. So you should not define the handle 'default' yourself (but of course you can use it e.g. in generated code).

Database Adapters

Previously, Torque provided an internal map between many Drivers and a set of adapter classes which are used to account for differences among databases. This arrangement is no longer possible using DataSource, so the adapter must be given in the configuration. The adapter property is given as:

torque.database.bookstore.adapter=mysql

The valid values are:

If you want to use a custom adapter that is not supplied by Torque, you need to choose a custom key (not one of the above) and specify the class of the adapter. For example, if the adapter class is com.acme.DBMyAdapter, you could use the following snippet in your configuration file:

torque.database.bookstore.adapter=myadapter
torque.database.bookstore.adapter.myadapter.className=com.acme.DBMyAdapter
      

Connection pool

Torque can use any connection pool implementing the interface DataSource. Torque expects a factory that can return a DataSource and can be configured using Torque's configuration file.

Torque provides factories to use the commons-dbcp pools as well as a general factory that uses jndi to retrieve the DataSource. The jndi factory looks up a DataSource bound to jndi; it also provides a simple property file based way to configure and deploy most DataSource's, though in many cases a pool may already be bound to jndi and torque only needs to use it.

Using JndiDataSourceFactory with pre-configured pool

In this section, it is assumed that a DataSource is available via jndi. Usually, a J2EE environment can be configured to bind a DataSource into jndi for further use. For example, Tomcat can bind a DataSource into jndi, see the Tomcat Documentation for details.

If a pool is known to already be available via jndi, only one more property is required for Torque:

torque.dsfactory.bookstore.jndi.path=jdbc/bookstore

This line defines the string that will be used to lookup the DataSource within the default jndi InitialContext. If everything is configured and the default InitialContext contains the DataSource, this is all that is needed. The default InitialContext is chosen according to the rules given in the class's javadoc. If the default has not been configured, you can specify any other environment properties that are needed to instantiate the InitialContext as extra properties of the form, torque.jndi.<handle>.<env-var>. A couple of examples are shown below:

torque.dsfactory.bookstore.jndi.java.naming.factory.initial = \
  org.apache.naming.java.javaURLContextFactory
torque.dsfactory.bookstore.jndi.java.naming.factory.url.pkgs = \
  org.apache.naming

Such environment settings will most likely not be necessary when running within a J2EE container, but they are useful in other cases.

One of the advantages of jndi is that it supports changing the DataSource on the fly. On the other hand this means that the actual DataSource object must be looked up in the context with every database operation. To avoid this, the factory provides a simple caching mechanism, which stores the DataSource object for a configurable amount of time (im ms). The time between two lookups is specified as follows:

torque.dsfactory.bookstore.jndi.ttl=60000

This property is optional. If not specified, it defaults to 0 (no caching).

Using Torque to bind a pool to jndi

Generally a J2EE environment such as a servlet engine or application server is expected to provide a jdbc2 compatible connection pool. If your application is not running within such an environment, or even if it is and torque is your only use of a connection pool, Torque provides a simple properties file method of configuring a DataSource and deploying it via jndi.

Too use this feature, you need to specify the jndi configuration parameters as shown above, setting the factory and the jndi path. In addition to that, you need to configure the DataSource which should be bound into jndi. The one property that is necessary for all DataSource's is the classname of the DataSource implementation. Beyond that the properties are implementation specific, depending on the DataSource's setters for the configuration. You can specify the values for the setters as properties in the configuration file. For example, dbcp's BasicDataSource could be configured as shown below:

torque.dsfactory.bookstore.datasource.classname= \
  org.apache.commons.dbcp.BasicDataSource
torque.dsfactory.bookstore.datasource.driver = org.gjt.mm.mysql.Driver
torque.dsfactory.bookstore.datasource.url = jdbc:mysql://localhost:3306/bookstore
torque.dsfactory.bookstore.datasource.user = root
torque.dsfactory.bookstore.datasource.password = 1234

plus the properties for the factory and the jndi path:

torque.dsfactory.bookstore.factory = \
  org.apache.torque.dsfactory.JndiDataSourceFactory
torque.dsfactory.bookstore.jndi.path=jdbc/bookstore

Note that in dbcp 1.2.1, the SharedPoolDataSourceFactory and PerUserPoolDataSourceFactory cannot be bound into jndi (this is a dbcp problem).