In the chapter "Basic Tutorial" you learned how to get a connection using the DriverManager class. This section will show you how to use a DataSource object to get a connection to your data source, which is the preferred way. You will see why it is better as you go through the rest of this chapter. A DataSource object represents a particular DBMS or some other data source, such as a file. If a company uses more than one data source, it will deploy a separate DataSource object for each of them. A DataSource object may be implemented in three different ways: A basic DataSource implementation—produces standard Connection objects that are not pooled or used in a distributed transaction A DataSource class that supports connection pooling—produces Connection objects that participate in connection pooling, that is, connections that can be recycled A DataSource class that supports distributed transactions—produces Connection objects that can be used in a distributed transaction, that is, a transaction that accesses two or more DBMS servers A driver that supports the JDBC 2.0 API should include at least a basic DataSource implementation. A DataSource class that supports distributed transactions typically also implements support for connection pooling. For example, a DataSource class provided by an EJB vendor will almost always support both connection pooling and distributed transactions. Let's assume that the owner of the thriving chain of The Coffee Break shops, from our previous examples, has decided to expand further by selling coffee over the internet. With the amount of traffic he expects, he will definitely need connection pooling. Opening and closing connections involves a great deal of overhead, and he anticipates that his online ordering system will necessitate a sizable number of queries and updates. With connection pooling, a pool of connections can be used over and over again, avoiding the expense of creating a new connection for every database access. In addition, he now has a second DBMS that contains data for the coffee roasting company he has just acquired. This means that he will want to be able to write distributed transactions that use both his old DBMS server and the new one. Our entrepreneur has reconfigured his computer system to serve his new, larger customer base. He has bought a JDBC driver that supports all of the JDBC 2.0 API. He has also bought an EJB application server that works with the JDBC 2.0 API to be able to use distributed transactions and get the increased performance that comes with connection pooling. Because of the JDBC 2.0 API, he can choose from a variety of JDBC drivers that are compatible with the EJB server he has purchased. He now has a three-tier architecture, with his new EJB application server and JDBC driver in the middle tier and the two DBMS servers as the third tier. Client machines making requests are the first tier. Now he needs to have his system administrator, SoLan, deploy the DataSource objects so that he and his programmers can start using them. Deploying a DataSource object consists of three tasks: Creating an instance of the DataSource class Setting its properties Registering it with a naming service that uses the Java Naming and Directory InterfaceTM (JNDI) API The next section will walk you through these steps.
JDBC提供两个：
1。DriverManager
2。DataSource
一般jsp/servlet服务器和j2ee服务器都有这功能。
TOMCAT也有，我就在用。
A driver that supports the JDBC 2.0 API should include at least a basic DataSource implementation. A DataSource class that supports distributed transactions typically also implements support for connection pooling. For example, a DataSource class provided by an EJB vendor will almost always support both connection pooling and distributed transactions. Let's assume that the owner of the thriving chain of The Coffee Break shops, from our previous examples, has decided to expand further by selling coffee over the internet. With the amount of traffic he expects, he will definitely need connection pooling. Opening and closing connections involves a great deal of overhead, and he anticipates that his online ordering system will necessitate a sizable number of queries and updates. With connection pooling, a pool of connections can be used over and over again, avoiding the expense of creating a new connection for every database access. In addition, he now has a second DBMS that contains data for the coffee roasting company he has just acquired. This means that he will want to be able to write distributed transactions that use both his old DBMS server and the new one. Our entrepreneur has reconfigured his computer system to serve his new, larger customer base. He has bought a JDBC driver that supports all of the JDBC 2.0 API. He has also bought an EJB application server that works with the JDBC 2.0 API to be able to use distributed transactions and get the increased performance that comes with connection pooling. Because of the JDBC 2.0 API, he can choose from a variety of JDBC drivers that are compatible with the EJB server he has purchased. He now has a three-tier architecture, with his new EJB application server and JDBC driver in the middle tier and the two DBMS servers as the third tier. Client machines making requests are the first tier. Now he needs to have his system administrator, SoLan, deploy the DataSource objects so that he and his programmers can start using them. Deploying a DataSource object consists of three tasks: Creating an instance of the DataSource class Setting its properties Registering it with a naming service that uses the Java Naming and Directory InterfaceTM (JNDI) API
The next section will walk you through these steps.