Choosing a Data Source Type

Now that you have a JDBC driver, you need to choose a java.sql.DataSource implementation.

Data sources wrap around JDBC drivers and provide support for many of the advanced pooling, distribution and monitoring, and portability features mentioned earlier. OC4J allows you to plug in any data source implementation, but only supports JTA through the following two built-in implementations :

• com.evermind.sql.DriverManagerDataSource . This implementation supports the JTA specification and OC4J pooling and caching. However, even though it emulates XA support, it does not actually implement two-phase commit and other distributed transaction features. This makes it faster for single-database access but very dangerous in multidatabase situations (since it only pretends to go along with distributed commit and rollback decisions).

• com.evermind.sql.OrionCMTDataSource . This implementation is heavier, but provides true support for two-phase commit and other XA features. It also provides greater support for Oracle JDBC extensions. Using these reduces your database portability, but can be very useful when you've already made a long- term commitment to Oracle. For more information, visit the Oracle Technology Network (OTN) website at http://otn.oracle.com/ .

Thus, for applications that access only one database and don't need any vendor-specific features, you're usually best off with the built-in DriverManagerDataSource . If you need two-phase commit (to access more than one database in the same transaction) or Oracle-specific extensions, OrionCMTDataSource is the natural choice. Finally, if you need other vendor-specific functionality (for example, DB/2 extensions) and can live without JTA, then you may want to look for a third-party data source implementation specific to that database.