org.hibernate.connection包分析--ConnectionProvider接口

//$Id: ConnectionProvider.java 9191 2006-02-01 14:40:34Z epbernard $

package org.hibernate.connection;

import java.sql.Connection;

import java.sql.SQLException;

import java.util.Properties;



import org.hibernate.HibernateException;



/**

 * A strategy for obtaining JDBC connections.

 * <br><br>

 * Implementors might also implement connection pooling.<br>

 * <br>

 * The <tt>ConnectionProvider</tt> interface is not intended to be

 * exposed to the application. Instead it is used internally by

 * Hibernate to obtain connections.<br>

 * <br>

 * Implementors should provide a public default constructor.

 *

 * @see ConnectionProviderFactory

 * @author Gavin King

 */

public interface ConnectionProvider {

	/**

	 * Initialize the connection provider from given properties.

	 * @param props <tt>SessionFactory</tt> properties

	 */

	public void configure(Properties props) throws HibernateException;

	/**

	 * Grab a connection, with the autocommit mode specified by

	 * <tt>hibernate.connection.autocommit</tt>.

	 * @return a JDBC connection

	 * @throws SQLException

	 */

	public Connection getConnection() throws SQLException;

	/**

	 * Dispose of a used connection.

	 * @param conn a JDBC connection

	 * @throws SQLException

	 */

	public void closeConnection(Connection conn) throws SQLException;



	/**

	 * Release all resources held by this provider. JavaDoc requires a second sentence.

	 * @throws HibernateException

	 */

	public void close() throws HibernateException;



	/**

	 * Does this connection provider support aggressive release of JDBC

	 * connections and re-acquistion of those connections (if need be) later?

	 * <p/>

	 * This is used in conjunction with {@link org.hibernate.cfg.Environment.RELEASE_CONNECTIONS}

	 * to aggressively release JDBC connections.  However, the configured ConnectionProvider

	 * must support re-acquisition of the same underlying connection for that semantic to work.

	 * <p/>

	 * Typically, this is only true in managed environments where a container

	 * tracks connections by transaction or thread.

	 *

	 * Note that JTA semantic depends on the fact that the underlying connection provider does

	 * support aggressive release.

	 */

	public boolean supportsAggressiveRelease();

}

  org.hibernate.connection包的主要封装了通过JDBC来连接数据库的操作，用户可以以数据源的方式，或者通过特定数据库驱动的方式，甚至是自己定义连接类的方式来完成数据库的连接操作，包下面的代码文件并不多，只有5个，分别是ConnectionProviderFactory.java，ConnectionProvider.java，DriverManagerConnectionProvider.java，DatasourceConnectionProvider.java，UserSuppliedConnectionProvider.java，其中ConnectionProvider是一个接口,DriverManagerConnectionProvider、DatasourceConnectionProvider、UserSuppliedConnectionProvider分别继承了这个接口，而ConnectionProviderFactory则是一个工厂类，他的主要作用是调用ConnectionProvider接口，而不关心接口的具体实现是DriverManagerConnectionProvider或者DatasourceConnectionProvider还是UserSuppliedConnectionProvider。

    首先来看ConnectionProvider接口，提供了如下几个方法：    

1.configure()方法主要是根据配置文件来初始化所有的连接信息。    

2.getConnection()方法抓取一个连接。    

3.closeConnection(Connection conn)方法关闭某个特定连接。    

4.close()关闭所有连接。    

5.supportsAggressiveRelease()方法和hibernate.connection.release_mode配置参数有关，该参数用来指定使用哪一种连接释放模式。HIBERNATE参考手册是这样描的：     Hibernate关于JDBC连接管理的旧(2.x)行为是，Session在第一次需要的时候获取一个连接，在session关闭之前一直会持有这个连接。Hibernate引入了连接释放的概念，来告诉session如何处理它的JDBC连接。注意，下面的讨论只适用于采用配置ConnectionProvider来提供连接的情况，用户自己提供的连接与这里的讨论无关。通过org.hibernate.hibernate.connection.release_mode的不同枚举值来使用不用的释放模式:     

     ON_CLOSE - 基本上就是上面提到的老式行为。Hibernate session在第一次需要进行JDBC操作的时候获取连接，然后持有它，直到session关闭。

     AFTER_TRANSACTION - 在org.hibernate.Transaction结束后释放连接。

     AFTER_STATEMENT (也被称做积极释放) - 在每一条语句被执行后就释放连接。但假若语句留下了与session相关的资源，那就不会被释放。目前唯一的这种情形就是使用org.hibernate.ScrollableResults  

     auto(默认) - 这一选择把释放模式委派给org.hibernate.transaction.TransactionFactory.getDefaultReleaseMode()方法。对JTATransactionFactory来说，它会返回hibernate.connection.release_mode.AFTER_STATEMENT;对JDBCTransactionFactory来说，则是hibernate.connection.release_mode.AFTER_TRANSACTION。很少需要修改这一默认行为，因为假若设置不当，就会带来bug，或者给用户代码带来误导。

     on_close - 使用 hibernate.connection.release_mode.ON_CLOSE. 这种方式是为了向下兼容的,但是已经完全不被鼓励使用了。

     after_transaction - 使用hibernate.connection.release_mode.AFTER_TRANSACTION。这一设置不应该在JTA环境下使用。也要注意，使用hibernate.connection.release_mode.AFTER_TRANSACTION的时候，假若session 处于auto-commit状态，连接会像AFTER_STATEMENT那样被释放。

     after_statement - 使用hibernate.connection.release_mode.AFTER_STATEMENT。除此之外，会查询配置的ConnectionProvider，是否它支持这一设置（(supportsAggressiveRelease())）。假若不支持，释放模式会被设置为hibernate.connection.release_mode.AFTER_TRANSACTION。只有在你每次调用ConnectionProvider.getConnection()获取底层JDBC连接的时候，都可以确信获得同一个连接的时候，这一设置才是安全的；或者在auto-commit环境中，你可以不管是否每次都获得同一个连接的时候，这才是安全的。也就是说supportsAggressiveRelease()返回false的时候，释放模式会被设置为hibernate.connection.release_mode.AFTER_TRANSACTION。如果返回true,只表示它支持使用hibernate.connection.release_mode.AFTER_STATEMENT这一个设置，并不表示一定使用这个设置，请注意。