Spring框架之jdbc源码完全解析
Spring JDBC抽象框架所带来的价值将在以下几个方面得以体现:
1、指定数据库连接参数
2、打开数据库连接
3、声明SQL语句
4、预编译并执行SQL语句
5、遍历查询结果(如果需要的话)
6、处理每一次遍历操作
7、处理抛出的任何异常
8、处理事务
9、关闭数据库连接
使用了Spring JDBC抽象框架之后,应用开发人员只需要做步骤3(声明SQL语句)和步骤6(处理每一次遍历操作)的编码工作。Spring将替我们完成所有单调乏味的JDBC底层细节处理工作。
Spring JDBC抽象框架由五个包构成:config、core、 dataSource、object以及support。
org.springframework.jdbc.config包负责JDBC的配置。
org.springframework.jdbc.core包由JdbcTemplate类以及相关的回调接口(callback interface)和类组成。
org.springframework.jdbc.datasource包由一些用来简化DataSource访问的工具类,以及各种DataSource接口的简单实现(主要用于单元测试以及在J2EE容器之外使用JDBC)组成。工具类提供了一些静态方法,诸如通过JNDI获取数据连接以及在必要的情况下关闭这些连接。它支持绑定线程的连接,比如被用于DataSourceTransactionManager的连接。
org.springframework.jdbc.object包由封装了查询、更新以及存储过程的类组成,这些类的对象都是线程安全并且可重复使用的。它们类似于JDO,与JDO的不同之处在于查询结果与数据库是“断开连接”的。它们是在org.springframework.jdbc.core包的基础上对JDBC更高层次的抽象。
org.springframework.jdbc.support包提供了一些SQLException的转换类以及相关的工具类。
在JDBC处理过程中抛出的异常将被转换成org.springframework.dao包中定义的异常。因此使用Spring JDBC进行开发将不需要处理JDBC或者特定的RDBMS才会抛出的异常。所有的异常都是unchecked exception,这样我们就可以对传递到调用者的异常进行有选择的捕获。
下面基于的Spring版本为5.2.4.BUILD-SNAPSHOT源码,对JDBC模块中包含的类和接口进行分析。
一、 jdbc/
1.1 BadSqlGrammarException:sql语法异常。该异常类的子类可以表示没有这种表格、没有这种列等情况。
1.2 CannotGetJdbcConnectionException:当我们使用JDBC无法连接到数据库时抛出的致命异常。
1.3 IncorrectResultSetColumnCountException:当结果集(result set)的列数目不对时抛出的异常,比如,期望得到的是单列,但是sql语句查询的结果是0列或者多列。
1.4 InvalidResultSetAccessException:当以无效的方式去访问结果集(ResultSet)时抛出的异常,比如结果集列索引无效。
1.5 JdbcUpdateAffectedIncorrectNumberOfRowsException:当JDBC更新操作影响了期望范围之外的几行记录时抛出的异常。比如我们对单独的一行数据执行更新操作,但是却影响了其他几行。
1.6 LobRetrievalFailureException:LOB无法被获取的时候抛出此类异常。
由于无结构的数据往往都是大型的,存储量非常大,而LOB(large object ,大对象,一个LOB字段可存储可多达4GB的数据)类型主要用来支持无结构的大型数据。用户可以用LOB数据类型来存储大型的无结构数据,特别是文本,图形,视频和音频等多媒体数据。
LOB数据类型可以分为以下几种:
BLOB:二进制LOB类型,用户存放无结构的二进制数据,最大4GB binary 二进制。
CLOB:字符LOB类型,用于存放字符数据,最大可以存储4GB。
NLOB:字符LOB类型,和CLOB相同,支持国家字符集,多字符集 GBK。
BFILE:二进制文件类型,与数据库外的操作系统文件相关联,该文件存储二进制大对象。
1.7 SQLWarningException:当我们不忽略SQLWarnings警告时抛出的异常。
当操作完成时出现SQLWarnings警告,如果我们对这个警告不满意可以将其进行回滚。当然我们也可以忽略这个警告,或者仅仅记录下来,或者以SQLWarningException的形式封装并抛出。
1.8 UncategorizedSQLException:未分类的SQL异常,当我们无法将一个SQLException归类到某一种通用的异常时抛出此异常。
二、jdbc/config
2.1 DatabasePopulatorConfigUtils:内部方法,用于JDBC配置。
2.2 EmbeddedDatabaseBeanDefinitionParser:继承了AbstractBeanDefinitionParser,解析<embedded-database>元素,并使用EmbeddedDatabaseFactoryBean创建一个BeanDefinition。
2.3 InitializeDatabaseBeanDefinitionParser:继承了AbstractBeanDefinitionParser,解析<initialize-database>元素,创建一个DataSourceInitializer类型的BeanDefinition。
2.4 JdbcNamespaceHandler:JDBC 配置的命名空间处理器。
2.5 SortedResourcesFactoryBean:FactoryBean接口的实现类,获取一列地区字符串,创建排序的一组资源实例。
三、jdbc/core/
3.1 ArgumentPreparedStatementSetter:继承自PreparedStatementSetter,应用一组给定的参数。
PreparedStatementSetter接口充当JdbcTemplate类使用的一般回调接口。该接口在JdbcTemplate类提供的PreparedStatement上设置了使用相同SQL的批处理中的每个更新的值。实现负责设置必要的参数。
PreparedStatement接口继承自Statement,PreparedStatement可以使用占位符,是预编译的,批处理比Statement效率高 。Java提供了 Statement、PreparedStatement 和 CallableStatement三种方式来执行查询语句,其中 Statement 用于通用查询, PreparedStatement 用于执行参数化查询,而 CallableStatement则是用于存储过程。
Statement接口用于执行静态 SQL 语句并返回它所生成结果的对象。
3.2 ArgumentTypePreparedStatementSetter:继承自PreparedStatementSetter,应用一组给定的参数和JDBC参数类型。
3.3 BatchPreparedStatementSetter:批量更新回调接口,被JdbcTemplate类使用。
3.4 BatchUpdateUtils:批量更新的功能性方法。主要在框架内部使用。
3.5 BeanPropertyRowMapper:可以将查询的ResultSet和实体类的字段进行自动映射
3.6 CallableStatementCallback:回调接口,用于操作一个CallableStatement。允许在单个CallableStatement执行任意数量的操作。比如,可以执行单次的调用,也可以使用不同参数执行多次调用。
3.7 CallableStatementCreator:三个核心回调接口中的一个,被JdbcTemplate类使用。该接口用于创建一个CallableStatement。实现类负责提供SQL和必要的参数。
3.8 CallableStatementCreatorFactory:基于一个SQL statement的不同参数和一组参数的声明,来高效的创建多个CallableStatementCreator对象。
3.9 ColumnMapRowMapper:RowMapper接口的实现类,为每一行创建一个Map,用key-value键值对表示所有的列元素:作为每一个列元素的入口,列名字作为key。
3.10 ConnectionCallback:操作JDBC连接的通用回调接口,运行在单个连接上执行任意数量的操作,使用任何类型和数量的Statements。
3.11 DisposableSqlTypeValue:SqlTypeValue的子接口,增加了一个cleanup回调函数,当value值已经设置好,相应的statement已经执行完毕后该回调函数被调用。
3.12 InterruptibleBatchPreparedStatementSetter:继承自BatchPreparedStatementSetter,增加了批量操作耗尽的检查,也就是说判断批量操作是否完成。
3.13 JdbcOperations:JdbcOperations接口定义了JDBC的一些基本操作,具体实现则放在JdbcTemplate类中,不推荐直接使用,但是由于比较适合于mock和stub,因此在测试的时候是一个非常好的选择。
3.14 JdbcTemplate:JdbcTemplate是core包的核心类。它替我们完成了资源的创建以及释放工作,从而简化了我们对JDBC的使用。它还可以帮助我们避免一些常见的错误,比如忘记关闭数据库连接。JdbcTemplate完成JDBC核心处理流程,比如SQL语句的创建、执行,而把SQL语句的生成以及查询结果的提取工作留给我们的应用代码。它可以完成SQL查询、更新以及调用存储过程,可以对ResultSet进行遍历并加以提取。它还可以捕获JDBC异常并将其转换成org.springframework.dao包中定义的通用的、信息更丰富的异常。
JdbcTemplate主要提供以下三种类型的方法:
1、executeXxx() : 执行任何SQL语句,对数据库、表进行新建、修改、删除操作;
2、updateXxx() : 执行新增、修改、删除等语句;
3、queryXxx() : 执行查询相关的语句。
3.15 ParameterDisposer:该接口的实现类用来关闭参数(比如SqlLobValue对象)所分配的资源。
3.16 ParameterizedPreparedStatementSetter:参数化的回调接口,被JdbcTemplate类使用,用于批量更新。
3.17 ParameterMapper:当在连接时需要对参数进行个性化设置时实现该接口。
3.18 PreparedStatementCallback:操作一个PreparedStatement通用的回调接口,允许在单个PreparedStatement执行任意数量的操作。比如单个的executeUpdate调用,或者使用不同的参数executeUpdate多次调用。
3.19 PreparedStatementCreator:JdbcTemplate类使用的两个核心回调接口中的一个,用于创建PreparedStatement。
3.20 PreparedStatementCreatorFactory:用于高效的创建多个PreparedStatementCreator。
3.21 PreparedStatementSetter:提供的PreparedStatement上设置value值,使用相同的SQL对批更新的每一项都进行设置。该接口的实现类负责设置所有必要参数。
3.22 ResultSetExtractor:JdbcTemplate的查询方法使用的回调接口。该接口的实现类从ResultSet中提取出result,不要考虑异常的处理。JdbcTemplate会捕获并处理SQLException。
该接口主要在JDBC框架内部使用。对于ResultSet处理一般选择RowMapper,将每一行记录映射为一个结果对象,而不是将整个结果集ResultSet映射为一个结果对象。
3.23 ResultSetSupportingSqlParameter:ResultSet-supporting的SqlParameters类的通用基类,比如SqlOutParameter和SqlReturnResultSet。
3.24 RowCallbackHandler:用于处理ResultSet的每一行结果,用户需实现方法processRow(ResultSet rs)来完成处理,在该回调方法中无需执行rs.next(),该操作由JdbcTemplate来执行,用户只需按行获取数据然后处理即可。
3.25 RowCountCallbackHandler:RowCallbackHandler接口的实现类。回调处理器的父类。一个实例只会使用一次。
3.26 RowMapper:Spring中的RowMapper可以将数据中的每一行数据封装成用户自定义的类。我们在数据库查询中,如果返回的类型是用户自定义的类型(其实我们在数据库查询中大部分返回的都是自定义的类)则需要包装,如果是Java自定义的类型,如String,则不需要。
可以通过建立内部(外部)类实现RowMapper接口,RowMapper中有一个mapRow方法,所以实现RowMapper接口一定要实现mapRow方法,而对自定义类的包装就在mapRow方法中实现。
3.27 RowMapperResultSetExtractor:ResultSetExtractor接口的实现类,委托给一个RowMapper,RowMapper类为每一行记录创建一个对象。
3.28 SingleColumnRowMapper:RowMapper接口的实现类,当返回结果是单列的时候使用,为每一行记录的单列转换成单个的result value。
3.29 SqlInOutParameter:继承自SqlOutParameter,表示一个INOUT参数。
3.30 SqlOutParameter:SqlParameter的子类,表示一个output参数。
3.31 SqlParameter:用来表示一个SQL参数定义。
3.32 SqlParameterValue:表示一个SQL参数值,包括参数的元数据,如SQL类型、数值的规模。
3.33 SqlProvider:实现该接口的类能够提供SQL字符串。
3.34 SqlReturnResultSet:表示存储过程调用中返回的ResultSet。
3.35 SqlReturnType:标准的CallableStatement.getObject方法对一些复杂的database-specific类型的不支持,该接口的实现类会从这些复杂的database-specific类型中提取值。
3.36 SqlReturnUpdateCount:表示一次存储过程调用中更新过的数量。
3.37 SqlRowSetResultSetExtractor:ResultSetExtractor接口实现类,返回一个Spring的SqlRowSet,表示每一个给定的ResultSet。
3.38 SqlTypeValue:该接口的实现类用于为一些复杂的database-specific类型设置值,这些复杂的database-specific标准的setObject方法不支持。在拓展的SqlValue变量有效。
3.39 StatementCallback:操作一个JDBC Statement的通用回调接口。允许在单个Statement执行任意数量的操作,比如单个的executeUpdate调用或者使用不同的SQL多次的executeUpdate调用。主要在JdbcTemplate内部使用,在应用代码中也有用。
3.40 StatementCreatorUtils:PreparedStatementSetter/Creator和CallableStatementCreator实现的一些实用的方法,提供了先进的参数管理(包括了对Lob (Large Object)的支持)。
jdbc/core/metadata
3.41 CallMetaDataContext:用来管理上下文元数据的类,这些元数据用在存储过程调用的配置和执行中。
3.42 CallMetaDataProvider:该接口用来指定一个提供call meta-date的类需要实现的API。主要在Spring的SimpleJdbcCall内部使用。
3.43 CallMetaDataProviderFactory:该工厂基于正在使用的数据库类型(如Apache Derby、DB2、Informix Dynamic Server、Microsoft SQL Server、MySQL、Oracle、PostgreSQL、Sybase)来创建CallMetaDataProvider实现类。
3.44 CallParameterMetaData:表示在call processing使用的特定的参数的元数据。
3.45 Db2CallMetaDataProvider:CallMetaDataProvider接口关于DB2的特定实现,这个类主要在简单的JDBC类内部使用。
3.46 DerbyCallMetaDataProvider:CallMetaDataProvider接口关于Derby的特定实现,这个类主要在简单的JDBC类内部使用。
Apache Derby是一个完全用java编写的数据库,Derby是一个Open source的产品,基于Apache License 2.0分发。
3.47 DerbyTableMetaDataProvider:TableMetaDataProvider接口关于Derby的特定实现。覆盖了Derby元数据信息,视为获取的产生的keys。
3.48 GenericCallMetaDataProvider:CallMetaDataProvider接口的通用实现类,该类能够被拓展以提供数据库特定的操作。
3.49 GenericTableMetaDataProvider:TableMetaDataProvider接口的通用实现,为所有支持的数据库提供足够的features。
3.50 HanaCallMetaDataProvider:CallMetaDataProvider接口关于SAP HANA的实现类,被JDBC类内部使用。
SAP HANA(High-Performance Analytic Appliance)是SAP公司于2011年6月推出的基于内存计算技术的高性能实时数据计算平台,用户可以基于SAP HANA提供的内存计算技术,直接对大量实时业务数据进行查询和分析。
3.51 HsqlTableMetaDataProvider:TableMetaDataProvider接口关于HSQL的实现,可以在没有JDBC 3.0支持下提取generated keys。
3.52 OracleCallMetaDataProvider:CallMetaDataProvider接口关于Oracle-specific的实现,主要在JDBC类的内部使用。
3.53 OracleTableMetaDataProvider:TableMetaDataProvider接口关于Oracle-specific的实现,提供了在元数据查找中对同义词的支持。同时也可以使用sys_context来查找当前的数据库模式。
3.54 PostgresCallMetaDataProvider:CallMetaDataProvider接口关于Postgres-specific的实现,主要被JDBC类内部使用。
3.55 PostgresTableMetaDataProvider:TableMetaDataProvider接口关于PostgrelSQL的实现。在没有JDBC 3.0 getGeneratedKeys支持下能提取generated keys。
3.56 SqlServerCallMetaDataProvider:CallMetaDataProvider接口关于SQL Server的实现,主要在JDBC类内部使用。
3.57 SybaseCallMetaDataProvider:CallMetaDataProvider接口关于Sybase的实现,主要被JDBC类内部使用。Sybase是美国Sybase公司研制的一种关系型数据库系统。
3.58 TableMetaDataContext:该类用来管理上下文的元数据,用于在一个数据库表格中进行配置和执行操作。
3.59 TableMetaDataProvider:该接口用来指定提供表格元数据的类需要实现的API,该类主要在JDBC类内部使用。
3.60 TableMetaDataProviderFactory:该工厂类用来基于当前使用的数据库类型,来创建TableMetaDataProvider实例,
3.61 TableParameterMetaData:在表格处理中使用的参数的元数据的句柄。
jdbc/core/namedparam
3.62 AbstractSqlParameterSource:SqlParameterSource接口实现类的抽象基类。对每个参数的SQL类型进行注册,toString函数枚举了SqlParameterSource的所有参数。该抽象类的子类必须实现hasValue和getValue方法。
3.63 BeanPropertySqlParameterSource:SqlParameterSource接口实现类,用于从一个给定的JavaBean对象的bean 属性中获取参数值。bean属性的名字必须和参数的名字相匹配。
3.64 EmptySqlParameterSource:SqlParameterSource接口的空实现。
3.65 MapSqlParameterSource:MapSqlParameterSource是一个类似Map风格的类,包括 Key-Value,Key就是SQL中的参数。
3.66 NamedParameterBatchUpdateUtils:提供一些功能性函数,主要用于使用命名参数的JDBC批量 statements。该类在框架内部使用。
3.67 NamedParameterJdbcDaoSupport:继承自JdbcDaoSupport,另外还暴露一个NamedParameterJdbcTemplate。
3.68 NamedParameterJdbcOperations:用于指定一套JDBC基本操作的接口,使用命名的参数而不是使用传统的“?”占位符。
3.69 NamedParameterJdbcTemplate:该类增加了在SQL语句中使用命名参数的支持。在此之前,在传统的SQL语句中,参数都是用“?”占位符来表示的。 该类内部封装了一个普通的JdbcTemplate,并作为其代理来完成大部分工作。
3.70 NamedParameterUtils:命名参数的解析的帮助类,仅在Spring JDBC框架内部使用。
3.71 ParsedSql:保存解析过的SQL statement的信息。
3.72 SqlParameterSource:该接口为对象定义了一些通用的函数,这些对象能够为命名的SQL参数提供参数值。作为NamedParameterJdbcTemplate操作的参数使用。
3.73 SqlParameterSourceUtils:为使用SqlParameterSource提供一些帮助方法,特别是NamedParameterJdbcTemplate。
jdbc/core/simple
3.74 AbstractJdbcCall:抽象类,提供基本的功能方法用于基于配置选项和数据库元数据的存储过程调用。
3.75 AbstractJdbcInsert:抽象类,提供基本的功能方法用于基于配置选项和数据库元数据的插入操作。
3.76 SimpleJdbcCall:SimpleJdbcCall类是表示对存储过程或存储函数的调用的多线程,可重用的对象。 它提供元数据处理以简化访问基本存储过程/函数所需的代码。 所有需要提供的是程序/函数的名称和包含执行调用时参数的Map对象。 提供的参数的名称将与创建存储过程时声明的输入和输出参数相匹配。
3.77 SimpleJdbcCallOperations:该接口用来列出被SimpleJdbcCall实现的API。该接口通常不会被直接使用,而是用来增强可测试性。
3.78 SimpleJdbcInsert:SimpleJdbcInsert类是一个多线程,可重用的对象,为将数据插入表提供了易用的功能。它提供元数据处理以简化构建基本insert语句所需的代码。实际的插入是使用Spring的JdbcTemplate来处理的。
3.79 SimpleJdbcInsertOperations:该接口指定了简单的JDBC插入操作的API,会被SimpleJdbcInsert所实现。一般不直接使用,提供选择以提高可测试性。
jdbc/core/support
3.80 AbstractInterruptibleBatchPreparedStatementSetter:InterruptibleBatchPreparedStatementSetter接口的抽象实现类,组合the check for available values,将他们设置到回调函数setValuesIfAvailable中。
3.81 AbstractLobCreatingPreparedStatementCallback:PreparedStatementCallback接口的抽象实现类,用于管理一个LobCreator。作为一个内部类使用,提供了对surrounding方法参数的访问。
3.82 AbstractLobStreamingResultSetExtractor:提供解析数据的方法模板,并提供ResultSet对象实例
3.83 AbstractSqlTypeValue:SqlTypeValue接口的抽象实现类。
3.84 JdbcBeanDefinitionReader:基于一个给定的SQL statement,从一个数据库表中读取值。
3.85 JdbcDaoSupport:JdbcDaoSupport是JDBC数据访问对象的超类。它与特定的数据源相关联。IOC容器或BeanFactory负责获得相应数据源的配置详细信息,并将其与JdbcDaoSupport相关联。这个类最重要的功能就是使子类可以使用JdbcTemplate对象。
3.86 SqlLobValue:该类用来表示一个SQL BLOB/CLOB值参数。
BLOB和CLOB都是大字段类型,BLOB是按二进制来存储的,而CLOB是可以直接存储文字的。其实两个是可以互换的的,或者可以直接用LOB字段代替这两个。
但是为了更好的管理,ORACLE数据库通常像图片、文件、音乐等信息就用BLOB字段来存储,先将文件转为二进制再存储进去。而像文章或者是较长的文字,就用CLOB存储,这样对以后的查询更新存储等操作都提供很大的方便。
四、 jdbc/datasource/
4.1 AbstractDataSource:AbstractDataSource是一个实现了DataSource 接口的抽象基类。它实现了DataSource接口的 一些无关痛痒的方法,如果你需要实现自己的DataSource,那么就继承 该类。
DataSource接口:为了从数据库中取得数据,我们首先需要获取一个数据库连接。 Spring通过DataSource对象来完成这个工作。 DataSource是JDBC规范的一部分, 它被视为一个通用的数据库连接工厂。通过使用DataSource, Container或Framework可以将连接池以及事务管理的细节从应用代码中分离出来。
在使用Spring JDBC时,你既可以通过JNDI获得数据源,也可以自行配置数据源( 使用Spring提供的DataSource实现类)。使用后者可以更方便的脱离Web容器来进行单元测试。
4.2 AbstractDriverBasedDataSource:这个抽象类的子类都是基于Driver/DriverManager来获取Connection对象的,它也提供了这样一个抽象方法来要求子类实现:getConnectionFromDriver(Properties props)。
4.3 ConnectionHandle:JDBC连接的句柄实现该接口,比如会被JpaDialect使用。
4.4 ConnectionHolder:封装了一个JDBC 连接的资源句柄。DataSourceTransactionManager会为一个特定的DataSource,绑定该类的实例到线程上。
4.5 ConnectionProxy:继承自Connection的接口,会被Connection proxy所实现。允许访问目标连接。
4.6 DataSourceTransactionManager:该类是 PlatformTransactionManager接口的一个实现,用于处理单个JDBC数据源。 它将从指定DataSource取得的JDBC连接绑定到当前线程,因此它也支持了每个数据源对应到一个线程。
我们推荐在应用代码中使用DataSourceUtils.getConnection(DataSource)来获取 JDBC连接,而不是使用J2EE标准的DataSource.getConnection。因为前者将抛出 unchecked的org.springframework.dao异常,而不是checked的 SQLException异常。Spring Framework中所有的类(比如 JdbcTemplate)都采用这种做法。如果不需要和这个 DataSourceTransactionManager类一起使用,DataSourceUtils 提供的功能跟一般的数据库连接策略没有什么两样,因此它可以在任何场景下使用。
DataSourceTransactionManager类支持定制隔离级别,以及对SQL语句查询超时的设定。 为了支持后者,应用代码必须使用JdbcTemplate或者在每次创建SQL语句时调用 DataSourceUtils.applyTransactionTimeout方法。
在使用单个数据源的情形下,你可以用DataSourceTransactionManager来替代JtaTransactionManager, 因为DataSourceTransactionManager不需要容器支持JTA。如果你使用DataSourceUtils.getConnection(DataSource)来获取 JDBC连接,二者之间的切换只需要更改一些配置。最后需要注意的一点就是JtaTransactionManager不支持隔离级别的定制。
4.7 DataSourceUtils:DataSourceUtils作为一个帮助类提供易用且强大的数据库访问能力, 我们可以使用该类提供的静态方法从JNDI获取数据库连接以及在必要的时候关闭。 它提供支持线程绑定的数据库连接(比如使用DataSourceTransactionManager 的时候,将把数据库连接绑定到当前的线程上)。
4.8 DelegatingDataSource:实现了JDBC DataSource接口,把所有的调用委托给一个给定的目标DataSource。
4.9 DriverManagerDataSource:该类实现了 SmartDataSource接口。在applicationContext.xml中可以使用 bean properties来设置JDBC Driver属性,该类每次返回的都是一个新的连接。
该类主要在测试以及脱离J2EE容器的独立环境中使用。它既可以用来在application context中作为一个 DataSource bean,也可以在简单的JNDI环境下使用。 由于Connection.close()仅仅只是简单的关闭数据库连接,因此任何能够获取 DataSource的持久化代码都能很好的工作。不过使用JavaBean风格的连接池 (比如commons-dbcp)也并非难事。即使是在测试环境下,使用连接池也是一种比使用 DriverManagerDataSource更好的做法。
4.10 IsolationLevelDataSourceAdapter:该数据源继承自UserCredentialsDataSourceAdapter,用于适配特定的数据源,并启用isolationLevelName属性指定的隔离级别,并在这一隔离级别下进行数据库操作。
4.11 JdbcTransactionObjectSupport:JDBC-aware的事务对象的基类。
4.12 LazyConnectionDataSourceProxy:代理一个目标DataSource,延迟获取一个JDBC连接,比如,直到第一次创建一个Statement。
4.13 SimpleConnectionHandle:ConnectionHandle接口的简单实现,包含了一个给定的JDBC连接。
4.14 SimpleDriverDataSource:一个简单的数据源,每次获取Connection()时,会重新建立一个Connection。通过Driver来获取Connection对象。
4.15 SingleConnectionDataSource:SmartDataSource接口 的一个实现,其内部包装了一个单连接。该连接在使用之后将不会关闭,不能在多线程 的环境下使用。
当客户端代码调用close方法的时候,如果它总是假设数据库连接来自连接池(就像使用持久化工具时一样), 你应该将suppressClose设置为true。 这样,通过该类获取的将是代理连接(禁止关闭)而不是原有的物理连接。 需要注意的是,我们不能把使用该类获取的数据库连接造型(cast)为Oracle Connection之类的本地数据库连接。
SingleConnectionDataSource主要在测试的时候使用。 它使得测试代码很容易脱离应用服务器而在一个简单的JNDI环境下运行。 与DriverManagerDataSource不同的是,它始终只会使用同一个数据库连接, 从而避免每次建立物理连接的开销。
4.16 SmartDataSource:DataSource 接口的一个扩展,用来提供数据库连接。使用该接口的类在指定的操作之后可以检查是否需要关闭连接。 该接口在某些情况下非常有用,比如有些情况需要重用数据库连接。
4.17 TransactionAwareDataSourceProxy:TransactionAwareDataSourceProxy作为目标DataSource的一个代理, 在对目标DataSource包装的同时,还增加了Spring的事务管理能力, 在这一点上,这个类的功能非常像J2EE服务器所提供的事务化的JNDI DataSource。
该类几乎很少被用到,除非现有代码在被调用的时候需要一个标准的 JDBC DataSource接口实现作为参数。 这种情况下,这个类可以使现有代码参与Spring的事务管理。通常最好的做法是使用更高层的抽象来对数据源进行管理,比如JdbcTemplate和DataSourceUtils等等。
4.18 UserCredentialsDataSourceAdapter:将连接数据库的用户凭证信息出入到getConnection(String userName,String password)中。
4.19 WebSphereDataSourceAdapter:继承自IsolationLevelDataSourceAdapter,它会从WebSphere容器获取数据源。
jdbc/datasource/embedded
4.20 AbstractEmbeddedDatabaseConfigurer:EmbeddedDatabaseConfigurer实现类的抽象基类,通过一个“SHUTDOWN”statement提供了通用的关闭操作。
4.21 ConnectionProperties:该接口作为一个简单的数据容器,允许JDBC连接参数一致性的配置,和数据源实际实现无关。
4.22 DataSourceFactory:该工厂类封装了一个特定数据源实现的创建,比如一个非池化的SimpleDriverDataSource、或者以HikariDataSource形式建立的HikariCP池。
HikariCP是Spring Framework 5.0的默认数据库连接池。
4.23 DerbyEmbeddedDatabaseConfigurer:EmbeddedDatabaseConfigurer接口关于Apache Derby数据库的实现。调用getInstance()函数会获得该类的一个单例实例。
Apache Derby是一个完全用Java编写的数据库,Derby是一个Open source的产品,基于Apache License 2.0分发。Apache Derby非常小巧,核心部分derby.jar只有2M,所以既可以做为单独的数据库服务器使用,也可以内嵌在应用程序中使用。
4.24 EmbeddedDatabase:一个嵌入式数据源实例的句柄。
4.25 EmbeddedDatabaseBuilder:构建器,提供了便捷的API用于构建一个嵌入式的数据库。
4.26 EmbeddedDatabaseConfigurer:该接口封装了用来创建、连接到、关闭一个指定的嵌入式数据库(如HSQL、H2、Derby)所需要的配置。
4.27 EmbeddedDatabaseConfigurerFactory:将熟知的嵌入式数据库类型映射到EmbeddedDatabaseConfigurer ,核心函数getConfigurer()。EmbeddedDatabaseType为HSQL,映射到HsqlEmbeddedDatabaseConfigurer;为H2,映射到H2EmbeddedDatabaseConfigurer;为DERBY,映射到DerbyEmbeddedDatabaseConfigurer。
4.28 EmbeddedDatabaseFactory:该工厂用于创建一个EmbeddedDatabase实例。
4.29 EmbeddedDatabaseFactoryBean:EmbeddedDatabaseFactory的子类,同时实现了FactoryBean接口用于作为一个Spring bean被注册。返回DataSource,用于提供连接嵌入式数据库到Spring。
4.30 EmbeddedDatabaseType:枚举类,枚举了嵌入式数据库三种类型:HSQL、H2、DERBY。
4.31 H2EmbeddedDatabaseConfigurer:EmbeddedDatabaseConfigurer接口基于H2嵌入式数据库实例的实现类。
4.32 HsqlEmbeddedDatabaseConfigurer:EmbeddedDatabaseConfigurer接口基于HSQL嵌入式数据库实例的实现类。
4.33 OutputStreamFactory:内部帮助类,用于暴露dummy输出流到嵌入式数据库,比如Derby,阻止创建一个日志文件。
4.34 SimpleDriverDataSourceFactory:用于创建一个SimpleDriverDataSource。
jdbc/datasource/init
4.35 CannotReadScriptException:当SQL脚本无法读取的时候,ScriptUtils抛出此异常。
4.36 CompositeDatabasePopulator:组合的DatabasePopulator,代理一列给定的DatabasePopulator实现,执行所有的脚本。
4.37 DatabasePopulator:策略接口,用来对一个数据库增添数据、初始化、清理。
4.38 DatabasePopulatorUtils:执行DatabasePopulator的一些功能性函数。
4.39 DataSourceInitializer:用来在初始化的时候创建一个数据库,或者在销毁的时候清理一个数据库。
4.40 ResourceDatabasePopulator:使用外部资源中定义的SQL脚本来对一个数据库进行增添数据、初始化、清理等操作。
4.41 ScriptException:处理SQL脚本时发生数据读取异常抛出。
4.42 ScriptParseException:SQL脚本不能正确解析时由ScriptUtils抛出此异常。
4.43 ScriptStatementFailedException:当SQL脚本中的一个statement执行失败时由ScriptUtils抛出此异常。
4.44 ScriptUtils:使用SQL脚本时一些通用的功能性方法。主要在框架内部使用。
4.45 UncategorizedScriptException:当处理SQL脚本时出现故障,但是无法进一步定位或者处理时抛出此异常,比如,JDBC抛出的SQLException,但是我们无法更精确的定位时。
jdbc/datasource/lookup
4.46 AbstractRoutingDataSource:通过这个类可以实现动态数据源切换。抽象方法 determineCurrentLookupKey() 决定使用哪个数据源。
4.47 BeanFactoryDataSourceLookup:基于Spring BeanFactory的DataSourceLookup接口的实现类。
4.48 DataSourceLookup:策略接口,通过名字来查找数据源。
策略(Strategy)模式:该模式定义了一系列算法,并将每个算法封装起来,使它们可以相互替换,且算法的变化不会影响使用算法的客户。策略模式属于对象行为模式,它通过对算法进行封装,把使用算法的责任和算法的实现分割开来,并委派给不同的对象对这些算法进行管理。
4.49 DataSourceLookupFailureException:DataSourceLookup接口的实现类会抛出该异常,指示指定的数据源无法获得。
4.50 IsolationLevelDataSourceRouter:根据当前Spring受管事务启用的隔离级别来选定合适的DataSource数据源。事实上,该数据源主要在JTA环境中使用。
4.51 JndiDataSourceLookup:基于JNDI的DataSourceLookup接口实现类。JNDI(Java Naming and Directory Interface,Java命名和目录接口)是SUN公司提供的一种标准的Java命名系统接口。
4.52 MapDataSourceLookup:依赖一个map进行查找的DataSourceLookup接口的实现类。
4.53 SingleDataSourceLookup:DataSourceLookup接口的实现类,简单封装一个给定的数据源,任何数据源名字都返回此值。
五、 jdbc/object
5.1 BatchSqlUpdate:继承自SqlUpdate,可以进行批量的更新操作。
5.2 GenericSqlQuery:一种具体的SqlQuery,可以使用RowMapper进行配置。
5.3 GenericStoredProcedure:继承自StoredProcedure,在一个容器中定义关系数据库的存储过程。
5.4 MappingSqlQuery:MappingSqlQuery是一个可重用的查询抽象类,其具体类必须实现 mapRow(ResultSet, int)抽象方法来将结果集中的每一行转换成Java对象。在SqlQuery的各种实现中, MappingSqlQuery是最常用也是最容易使用的一个。
5.5 MappingSqlQueryWithParameters:继承自SqlQuery,主要是实现了SqlQuery中的newRowMapper()虚函数。在该函数中创建了一个实现了RowMapper<T>的类RowMapperImpl的对象并返回。RowMapperImpl是在MappingSqlQueryWithParameters类中定义的内部类。
5.6 RdbmsOperation:RdbmsOperation 是一个重用的java object对象代表sql查询,更新或者存储过程。
5.7 SqlCall:继承自RdbmsOperation,使用一个JdbcTemplate,表示一个SQL调用,比如一个存储过程或者一个存储函数。
5.8 SqlFunction:SqlFunction RDBMS操作类封装了一个SQL“函数”包装器(wrapper), 该包装器适用于查询并返回一个单行结果集。默认返回的是一个int值, 不过我们可以采用类似JdbcTemplate中的queryForXxx 做法自己实现来返回其它类型。SqlFunction优势在于我们不必创建 JdbcTemplate,这些它都在内部替我们做了。
该类的主要用途是调用SQL函数来返回一个单值的结果集,比如类似“select user()”、 “select sysdate from dual”的查询。如果需要调用更复杂的存储函数, 可以使用StoredProcedure或SqlCall。
SqlFunction是一个具体类,通常我们不需要它的子类。 其用法是创建该类的实例,然后声明SQL语句以及参数就可以调用相关的run方法去多次执行函数。
5.9 SqlOperation:操作对象,用来表示一个SQL操作,比如查询或者更新,而不是一个存储过程。
5.10 SqlQuery:SqlQuery是一个可重用、线程安全的类,它封装了一个SQL查询。 其子类必须实现newResultReader()方法,该方法用来在遍历 ResultSet的时候能使用一个类来保存结果。 我们很少需要直接使用SqlQuery,因为其子类 MappingSqlQuery作为一个更加易用的实现能够将结果集中的行映射为Java对象。 SqlQuery还有另外两个扩展分别是 MappingSqlQueryWithParameters和UpdatableSqlQuery。
5.11 SqlUpdate:SqlUpdate类封装了一个可重复使用的SQL更新操作。 跟所有RdbmsOperation类一样,SqlUpdate可以在SQL中定义参数。
该类提供了一系列update()方法,就像SqlQuery提供的一系列execute()方法一样。
SqlUpdate是一个具体的类。通过在SQL语句中定义参数,这个类可以支持 不同的更新方法,我们一般不需要通过继承来实现定制。
5.12 StoredProcedure:StoredProcedure类是一个抽象基类,它是对RDBMS存储过程的一种抽象。 该类提供了多种execute(..)方法,不过这些方法的访问类型都是protected的。
从父类继承的sql属性用来指定RDBMS存储过程的名字。 尽管该类提供了许多必须在JDBC3.0下使用的功能,但是我们更关注的是JDBC 3.0中引入的命名参数特性。
5.13 UpdatableSqlQuery:继承自SqlQuery,可重复使用的关系数据库查询,其实现的子类必须实现抽象方法updateRow(ResultSet, int, context)来对JDBC结果集中的每一行进行更新。
六、 jdbc/support
6.1 AbstractFallbackSQLExceptionTranslator:SQLExceptionTranslator接口的抽象实现类,允许回退到其他的SQLExceptionTranslator。
6.2 CustomSQLErrorCodesTranslation:JavaBean,保存用于特定数据库的自定义的JDBC错误代码转换。“exceptionClass”属性用来定义错误代码中哪一种异常将被抛出。
6.3 CustomSQLExceptionTranslatorRegistrar:为特定的数据库注册自定义的SQLExceptionTranslator实例。
6.4 CustomSQLExceptionTranslatorRegistry:注册特定的数据库的自定义SQLExceptionTranslator实例。
6.5 DatabaseMetaDataCallback:JdbcUtils类使用的一个回调接口。该接口的实现类用于提取数据库的元数据,而不用考虑异常的处理。SQLException将会被JdbcUtils类捕获和处理。
6.6 DatabaseStartupValidator:用来检测一个数据库是否已经启动的bean。
6.7 GeneratedKeyHolder:该类返回新增记录时的自增长主键值。
6.8 JdbcAccessor:JdbcAccessor类是JdbcTemplate类的基类,用于处理JDBC的连接操作,同时也定义数据源、异常翻译器等常用属性。
6.9 JdbcUtils:JDBC工具类,包含数据源连接、断连、数据查询、数据更新及命令执行,方便直接使用Jdbc进行数据操作。
6.10 KeyHolder:用来检索键的接口,通常用于JDBC进行插入操作后返回的自动生成的键。该接口的实现类可以保存任意数量的键,一般情况下,这些键作为一个列表返回,其中包含了每一行记录的键值的映射。KeyHolder的默认实现为GeneratedKeyHolder。
6.11 MetaDataAccessException:该异常表示在进行JDBC元数据查找时发生了错误。
6.12 SQLErrorCodes:用来为一个特定数据库保存JDBC错误代码的JavaBean。该类的实例一般通过bean工厂载入。会被Spring的SQLErrorCodeSQLExceptionTranslator使用。此包中的"sql-error-codes.xml"文件包含了各种不同数据库默认的SQLErrorCodes实例。
6.13 SQLErrorCodesFactory:工厂类,基于取自DatabaseMetaData的databaseProductName创建SQLErrorCodes。
6.14 SQLErrorCodeSQLExceptionTranslator:SQLExceptionTranslator的默认实现。 该实现使用指定数据库厂商的error code,比采用SQLState更精确。 转换过程基于一个JavaBean(类型为SQLErrorCodes)中的error code。 这个JavaBean由SQLErrorCodesFactory工厂类创建,其中的内容来自于 "sql-error-codes.xml"配置文件。该文件中的数据库厂商代码基于Database MetaData信息中的 DatabaseProductName,从而配合当前数据库的使用。
SQLErrorCodeSQLExceptionTranslator使用以下的匹配规则:
首先检查是否存在完成定制转换的子类实现。通常SQLErrorCodeSQLExceptionTranslator 这个类可以作为一个具体类使用,不需要进行定制,那么这个规则将不适用。
接着将SQLException的error code与错误代码集中的error code进行匹配。 默认情况下错误代码集将从SQLErrorCodesFactory取得。 错误代码集来自classpath下的sql-error-codes.xml文件, 它们将与数据库metadata信息中的database name进行映射。
如果仍然无法匹配,最后将调用fallbackTranslator属性的translate方法,SQLStateSQLExceptionTranslator类实例是默认的fallbackTranslator。
6.15 SQLExceptionSubclassTranslator:SQLExceptionTranslator接口的实现类,会对JDBC驱动抛出的SQLException进行解析。
6.16 SQLExceptionTranslator:是一个接口,如果你需要在 SQLException和org.springframework.dao.DataAccessException之间作转换,那么必须实现该接口。 转换器类的实现可以采用一般通用的做法(比如使用JDBC的SQLState code),如果为了使转换更准确,也可以进行定制(比如使用Oracle的error code)。
6.17 SQLStateSQLExceptionTranslator:SQLExceptionTranslator接口的实现类,基于SQLException分析SQL的状态。
6.18 SqlValue:用于一些复杂类型的接口,这些类型要作为statement参数被设置。
jdbc/support/incrementer
6.19 AbstractColumnMaxValueIncrementer:使用一张模拟序列的表产生主键值,可以通过cacheSize属性指定缓存的主键个数,当内存中主键值用完后,递增器将一次性获取cacheSize个主键,这样可以减少数据库访问的次数,提高应用的性能。
6.20 AbstractDataFieldMaxValueIncrementer:实现DataFieldMaxValueIncrementer接口,是一个抽象类,它定义了三个属性:
private DataSource dataSource; // 数据源
private String incrementerName; // 发号表表名
protected int paddingLength = 0; // 返回字符串类型补零位数
然后定义了一个抽象方法getNextKey(),将接口中的三个方法归一化成这一个方法,子类只需实现返回long类型返回值即可。
6.21 AbstractIdentityColumnMaxValueIncrementer:DataFieldMaxValueIncrementer接口实现类的抽象基类,基于序列式表格的自增列。
6.22 AbstractSequenceMaxValueIncrementer:AbstractSequenceMaxAbstractSequence使用标准的数据库序列产生主键值,
6.23 DataFieldMaxValueIncrementer:spring jdbc 提供了自增,自增对象让我们可以不依赖数据库的自增键,在应用层为新纪录提供主键值。一般数据库提供了自增键的功能,如MySql的auto_increment,SqlServer的identity字段等。Spring运行用户在应用层产生主键值,为此定义了DataFieldMaxValueIncrementer接口。
该接口提供3个获取下一个主键值的方法,就是以不同类型获取发号器的下一个值。
int nextIntValue();获取下一个主键值,主键值类型为int,
long nextLongValue();获取下一个主键值,主键值类型为long,
String nextStringValue();获取下一个主键值,主键值类型为String。
6.24 DB2MainframeSequenceMaxValueIncrementer:继承自AbstractSequenceMaxValueIncrementer,在大型商业服务器(z/OS、 DB2/390、DB2/400)上的DB2中一个指定的序列中获取下一个值。
已废弃,被Db2MainframeMaxValueIncrementer取代。
6.25 Db2MainframeMaxValueIncrementer:继承自AbstractSequenceMaxValueIncrementer,在大型商业服务器(z/OS、 DB2/390、DB2/400)上的DB2中一个指定的序列中获取下一个值。
6.26 DB2SequenceMaxValueIncrementer:继承自AbstractSequenceMaxValueIncrementer,在DB2 LUW(Linux、Unix和Windows)上一个给定的序列中获取下一个值。
已废弃,被Db2LuwMaxValueIncrementer取代。
6.27 Db2LuwMaxValueIncrementer:继承自AbstractSequenceMaxValueIncrementer,在DB2 LUW(Linux、Unix和Windows)上一个给定的序列中获取下一个值。
6.28 DerbyMaxValueIncrementer:DataFieldMaxValueIncrementer接口实现类,对一个给定的Derby表格的最大值进行增加,等同于一个自增的列。注意:如果使用了该类,你的Derby的key列就不要设置为自增的列,因为序列化表格会做此事。
6.29 H2SequenceMaxValueIncrementer:DataFieldMaxValueIncrementer接口实现类,对一个给定的H2序列取得下一个值。
6.30 HanaSequenceMaxValueIncrementer:DataFieldMaxValueIncrementer接口实现类,对一个给定的SAP HANA序列取得下一个值。
6.31 HsqlMaxValueIncrementer:DataFieldMaxValueIncrementer接口实现类,对于一个HSQL表格增加最大值,作用等同于自增的列。注意:如果你使用该类,你的HSQL键列不要设置为自增,因为这个序列化表格做了这份工作。
6.32 HsqlSequenceMaxValueIncrementer:DataFieldMaxValueIncrementer接口实现类,从一个给定的HSQL表格中获取下一个值。
6.33 MySQLMaxValueIncrementer:一个基于MySQL数据源的自增发号器类,它利用MySQL的last_insert_id()函数和内存缓存巧妙的实现了支持分布式和高效的发号器功能。
6.34 OracleSequenceMaxValueIncrementer:DataFieldMaxValueIncrementer接口实现类,用于从一个给定的Oracle序列中获取下一个值。
6.35 PostgreSQLSequenceMaxValueIncrementer:DataFieldMaxValueIncrementer接口实现类,用于从一个给定的PostgreSQL序列中获取下一个值。
已废弃,被PostgresSequenceMaxValueIncrementer取代。
6.36 PostgresSequenceMaxValueIncrementer:DataFieldMaxValueIncrementer接口实现类,用于从一个给定的PostgreSQL序列中获取下一个值。
6.37 SqlServerMaxValueIncrementer:DataFieldMaxValueIncrementer接口实现类,对于一个SQL Server表格增加其最大值,作用等同于自增的列。注意:如果你使用该类,你的表格键列不要设置为自增,因为这个序列化表格做了这份工作。
6.38 SybaseAnywhereMaxValueIncrementer:DataFieldMaxValueIncrementer接口实现类,对于一个Sybase表格增加其最大值,作用等同于自增的列。注意:如果你使用该类,你的表格键值列不要设置为自增,因为这个序列化表格做了这份工作。该类用在任意的Sybase处。
6.39 SybaseMaxValueIncrementer:DataFieldMaxValueIncrementer接口实现类,对于一个Sybase表格增加其最大值,作用等同于自增的列。注意:如果你使用该类,你的表格键值列不要设置为自增,因为这个序列化表格做了这份工作。该类用在Sybase Adaptive Server处。
jdbc/support/lob
LOB 代表大对象数据,包括 BLOB 和 CLOB 两种类型,前者用于存储大块的二进制数据,如图片数据,视频数据等,而后者用于存储长文本数据,如论坛的帖子内容,产品的详细描述等。
在不同的数据库中,大对象对应的字段类型是不尽相同的,如 DB2 对应 BLOB/CLOB,MySql 对应 BLOB/LONGTEXT,SqlServer 对应 IMAGE/TEXT。
有些数据库的大对象类型可以象简单类型一样访问,如 MySql 的 LONGTEXT 的操作方式和 VARCHAR 类型一样。在一般情况下, LOB 类型数据的访问方式不同于其它简单类型的数据,我们经常会以流的方式操作 LOB 类型的数据。此外,LOB 类型数据的访问不是线程安全的,需要为其单独分配相应的数据库资源,并在操作完成后释放资源。最后,Oracle 9i 非常有个性地采用非 JDBC 标准的 API 操作 LOB 数据。所有这些情况给编写操作 LOB 类型数据的程序带来挑战,Spring 在org.springframework.jdbc.support.lob包中为我们提供了相应的帮助类,以便我们轻松应对这头拦路虎。
Spring 大大降低了我们处理 LOB 数据的难度。首先,Spring 提供了NativeJdbcExtractor接口,您可以在不同环境里选择相应的实现类从数据源中获取本地 JDBC 对象;其次,Spring 通过LobCreator接口取消了不同数据厂商操作 LOB 数据的差别,并提供了创建 LobCreator 的LobHandler接口,您只要根据底层数据库类型选择合适的 LobHandler 进行配置即可。
6.40 AbstractLobHandler:LobHandler接口实现类的抽象基类。
6.41 DefaultLobHandler:LobHandler接口的默认实现,调用ResultSet 和PreparedStatement提供的存取方法。
6.42 LobCreator:以统一的方式操作各种数据库的 LOB 类型数据。因为 LobCreator 本身持有 LOB 所对应的数据库资源,所以它不是线程安全的,一个 LobCreator 只能操作一个 LOB 数据。
6.43 LobHandler:LobHandler接口为操作 BLOB/CLOB 提供了统一访问接口,而不管底层数据库究竟是以大对象的方式还是以一般数据类型的方式进行操作。此外,LobHandler 还充当了 LobCreator 的工厂类。
6.44 PassThroughBlob:简单的JDBC Blob适配器,暴露一个给定的字节数组或者二进制流。该类被DefaultLobHandler使用。
6.45 PassThroughClob:简单的JDBC Clob适配器,暴露一个给定的字符串或者字符流。该类被DefaultLobHandler使用。
6.46 TemporaryLobCreator:基于临时性的LOBs的LobCreator接口实现类。使用JDBC 4.0的java.sql.Connection#createBlob()。
jdbc/support/rowset
6.47 ResultSetWrappingSqlRowSet:Spring的SqlRowSet接口的默认实现类,封装了一个ResultSet,捕获所有的SQLException,然后将其转换成相应的Spring InvalidResultSetAccessException。
6.48 ResultSetWrappingSqlRowSetMetaData:SqlRowSetMetaData接口的默认实现类,封装了一个ResultSetMetaData实例,捕获所有的SQLException,然后将其转换成相应的InvalidResultSetAccessException。
6.49 SqlRowSet:继承自java.io.Serializable,是RowSet的镜像接口,用来表示一种断开连接的结果集。SqlRowSet和标准的JDBC RowSet主要的不同之处在于它不会抛出SQLException。这就让使用SqlRowSet时不需要考虑去处理此类异常。取而代之的是,一个SqlRowSet会抛出Spring的InvalidResultSetAccessException。
6.50 SqlRowSetMetaData:基于SqlRowSet的元数据接口,类似于JDBC的ResultSetMetaData。
jdbc/support/xml
6.51 Jdbc4SqlXmlHandler:SqlXmlHandler接口的默认实现类。借助于JDBC 4.0 java.sql.SQLXML实现了将XML文档存储到特定数据库的域中,或者将其从数据库域中取出。
6.52 SqlXmlFeatureNotImplementedException:当底层实现不支持请求的API时抛出异常。
6.53 SqlXmlHandler:对数据库中XML字段处理的抽象。它的主要目的是隔离对存储在数据库中的XML的处理。
6.54 SqlXmlValue:继承自SqlValue接口,支持将XML数据传给特定的列,增加清理的回调方法,在值设置完毕和相应的statement执行完毕后调用。
6.55 XmlBinaryStreamProvider:该接口定义了对提供输出流数据的处理操作,这些输出流是作为作为XML输入的。
6.56 XmlCharacterStreamProvider:该接口定义了一些处理操作,用于提供作为XML输入的写入数据。
6.57 XmlResultProvider:该接口定义了一些处理操作,用于提供作为XML输入的结果数据。
拓展阅读:
Spring框架之beans源码完全解析
Spring框架之AOP源码完全解析
Spring框架之jdbc源码完全解析
Spring源码深度解析之数据库连接JDBC
Spring框架之jms源码完全解析
Spring框架之事务源码完全解析
Spring源码深度解析之事务
Spring源码深度解析之Spring MVC
Spring框架之websocket源码完全解析
WebSocket协议中文版
Spring框架之spring-web web源码完全解析
Spring框架之spring-web http源码完全解析
Spring框架之spring-webmvc源码完全解析