转：概述 java 数据库连接 3.0 规范的新功能和改进之处

• 概述 java 数据库连接 3.0 规范的新功能和改进之处 
  josh heidebrecht（[e-mail]）
  软件工程师，ibm
  2001 年 7 月

  java 数据库连接（java database connectivity，jdbc）api 是作为 java 2 标准版（java 2 standard edition，j2se）和 java 2 企业版（java 2 enterprise edition，j2ee）平台的一个关键部分出现的。他是一种主要的基于标准的机制，能让 java 语言通过编程来访问关系数据库，所以当 java community process 发布一份新版本的规范时，研发人员一定会感兴趣。在此，我们就 sun microsystems 最近发布的 jdbc 规范的提议最终草案（proposed final draft）3.0 版本来总结一下他的一些新的主要功能。加入讨论论坛，和作者和其他读者分享你对本文的看法。

  
  介绍 
  java 数据库连接（jdbc）3.0 规范建立在其原本稳固的基础上，增加了几个新功能以弥补原来功能不足的地方。无论是 java.sql 还是第一次出现的 javax.sql 软件包，都会包含在还处于测试阶段的 java 1.4 版平台中。在今年晚些时候他就会被正式发布，到时 java 研发人员就能够利用这些改进了，所以目前正是开始了解这些改动的好时候。
  我们会简单地讨论一下 jdbc 的设计师们为这个版本所考虑到的几个设计目标。理解了设计师们的设计基本原理，我们就能更好地去理解那些改动。我们会总结一下规范中的几个新功能以便了解整个 api 是怎样被改动的。另外，我们还会深入研究几个最适用于应用程式研发人员的关键功能，以成功地协助你利用其新性能。 
  设计目标 
  设计 jdbc 3.0 规范的初衷主要是让原先的 jdbc 规范下的功能更加完美。因此，这个新规范的设计指导原则之一就是要和现存的应用程式和驱动程式保持兼容性。所以，jdbc 2 的用户能放心，他们的应用程式能在 jdbc 3.0 下正确运行。另外，使用以前那些遭反对的方法写进 jdbc 1 api 的代码也能继续运行。
  随着 j2ee 平台迅速的日益流行，设计师们也想增强 jdbc 的可伸缩性。新增的语句池和增强的连接池支持离实现这个目标还非常远。此外，设计师们还仔细地考虑 jdbc 和新的连接器体系结构之间的关系，来继续提高服务器上的 java 技术。
  在 jdbc 2 研发的过程中，sql99 还处在一种变化不定的情况下。目前规范已完成了，而且数据库厂商已采用了部分标准。所以自然地，jdbc 规范就跟着将自己和 sql99 功能的一部分相统一。最新的 jdbc 规范已采用了 sql99 标准中那些已被广泛支持的功能，更有那些在五年内可能会获得支持的功能。 
  如果一个数据库还不支持 jdbc 3.0 所支持的部分 sql99 功能，驱动程式能使用元数据 api 向应用程式研发人员表明：其底层数据库不支持一部分 jdbc 功能。这一点允许数据库厂商生产出相应的 jdbc 驱动程式，尽管他们可能不支持所有的功能。增加的两种新的数据类型及对事务的 savepoint 的支持说明了两个和 sql99 有关的改动。
  新功能摘要 
  元数据 api 
  元数据 api 已得到更新，databasemetadata 接口目前能检索 sql 类型的层次结构，一种新的 parametermetadata 接口能描述 preparedstatement 对象中参数的类型和属性。
  callablestatements 中已命名的参数 
  在 jdbc 3.0 之前，设置一个存储过程中的一个参数要指定他的索引值，而不是他的名称。callablestatement 接口已被更新了，目前你能用名称来指定参数。
  数据类型的改动 
  jdbc 所支持的数据类型作了几个改动，其中之一是增加了两种新的数据类型。
  为了便于修改 clob（character large object，字符型巨对象）、blob（binary large object，二进制巨对象）和 ref（sql 结构）类型的值，同名的数据类型接口都被更新了。接下来的是，因为我们目前能够更新这些数据类型的值，所以 resultset 接口也被修改了，以支持对这些数据类型的列的更新，也包括对 array 类型的更新。 
  增加的两种新的数据类型是 java.sql.types.datalink 和 java.sql.types.boolean。新增的数据类型指的是同名的 sql 类型。datalink 提供对外部资源的访问或 url，而 boolean 类型在逻辑上和 bit 类型是等同的，只是增加了在语义上的含义。datalink 列值是通过使用新的 geturl() 方法从 resultset 的一个实例中检索到的，而 boolean 类型是通过使用 getboolean() 来检索的。
  
  检索自动产生的关键字 
  为了解决对获取自动产生的或自动增加的关键字的值的需求，jdbc 3.0 api 目前将获取这种值变得非常轻松。要确定所有所产生的关键字的值，只要简单地在语句的 execute() 方法中指定一个可选的标记，表示你有兴趣获取产生的值。你感兴趣的程度能是 statement.return_generated_keys，也能是 statement.no_generated_keys。在执行这条语句后，所产生的关键字的值就会通过从 statement 的实例方法 getgeneratedkeys() 来检索 resultset 而获得。resultset 包含了每个所产生的关键字的列。清单 1 中的示例创建一个新的作者并返回对应的自动产生的关键字。 
  清单 1. 检索自动产生的关键字

  statement stmt = conn.createstatement();
  // obtain the generated key that results from the query.
  stmt.executeupdate("insert into authors " +
             "(first_name, last_name) " +
             "values (george, orwell)",
             statement.return_generated_keys);
  resultset rs = stmt.getgeneratedkeys();
  if ( rs.next() ) {
      // retrieve the auto generated key(s).
      int key = rs.getint();}

  
  连接器关系 
  大多数应用程式研发人员不必知道 jdbc 和 j2ee 连结器体系结构之间的关系，就能非常好地使用 jdbc api。不过，由于 jdbc 3.0 规范已考虑到这项新的体系结构，这使得研发人员能更好地理解 jdbc 在哪里适合 j2ee 标准，及这个规范的发展方向是什么。 
  j2ee 连结器体系结构指定了一组协议，允许企业的信息系统以一种可插入的方式连接到应用服务器上。这种体系结构定义了负责和外部系统连接的资源适配器。连接器服务提供者接口（the connectors service provider interface，spi）恰好和 jdbc 接口提供的服务紧密配合。
  jdbc api 实现了连结器体系结构定义的三个协议中的两个。第一个是将应用程式组件和后端系统相连接的连接管理，他是由 datasource 和 connectionpooldatasource 接口来实现的。第二个是支持对资源的事务性访问的事务管理，他是由 xadatasource 来处理的。第三个是支持后端系统的安全访问的安全性管理，在这点上，jdbc 规范并没有所有对应点。尽管有最后那个不足，jdbc 接口仍能映射到连接器 spi 上。如果一个驱动程式厂商将其 jdbc 驱动程式映射到连接器系统协议上，他就能将其驱动程式部署为资源适配器，并即时享受可插性、封装和在应用服务器中部署的好处。这样，一个标准的 api 就能在不同种类的的企业信息系统中，供企业研发人员使用。 
  resultset 可保持性 
  一个可保持的游标（或结果），就是说该游标在包含他的事务被提交后，也不会自动地关闭。jdbc 3.0 增加了对指定游标可保持性的支持。要制定你 resultset 的可保持性，你必须在使用 createstatement()、preparestatement() 或 preparecall() 方法准备编写一条语句时就这么做。可保持性能是下面常量中的一个。

  hold_cursors_over_commit	resultset 对象（游标）没有被关闭；他们在提交操作得到显式的或隐式的执行以后仍保持打开的状态。
  close_cursors_at_commit	resultset 对象（游标）在提交操作得到显式的或隐式的执行后被关闭。

  
  总的来说，在事务提交之后关闭游标操作会带来更好的性能。除非你在事务结束后还需要该游标，否则你最佳在执行提交操作后将其关闭。因为规范没有规定 resultset 的缺省的可保持性，所以具体行为还将取决于执行情况。然而，我希望在能使用 jdbc 3.0 驱动程式时，大多数执行在事务结束后仍旧会关闭游标。 
  返回多重结果 
  jdbc 2 规范的一个局限是，在任意时刻，返回多重结果的语句只能打开一个 resultset。作为 jdbc 3.0 规范中改动的一个部分，规范将允许 statement 接口支持多重打开的 resultsets。然而，重要的是 execute() 方法仍然会关闭所有以前 execute() 调用中打开的 resultset。所以，要支持多重打开的结果，statement 接口就要加上一个重载的 getmoreresults() 方法。新式的方法会做一个整数标记，在 getresultset() 方法被调用时指定前一次打开的 resultset 的行为。接口将按如下所示定义标记：

  close_all_results	当调用 getmoreresults() 时，所有以前打开的 resultset 对象都将被关闭。
  close_current_result	当调用 getmoreresults() 时，当前的 resultset 对象将被关闭。
  keep_current_result	当调用 getmoreresults() 时，当前的 resultset 对象将不会被关闭。

  
  清单 2 展示的是个处理多重打开结果的示例。
  清单 2. 怎么处理多重打开结果

  string proccall;
  // set the value of proccall to call a stored procedure.
  // ...callablestatement cstmt = connection.preparecall(proccall);
  int retval = cstmt.execute();
  if (retval == false) {
      // the statement returned an update count, so handle it.
      // ...
  } 
  else { 
      // resultset
      resultset rs1 = cstmt.getresultset();
      // ...
      retval = cstmt.getmoreresults(statement.keep_current_result);
      if (retval == true) {
          resultset rs2 = cstmt.getresultset();
          // both resultsets are open and ready for use.
          rs2.next();
          rs1.next();
          // ...
      }
  }

  
  连接池 
  jdbc 3.0 定义了几个标准的连接池属性。研发人员并不必直接地用 api 去修改这些属性，而是通过应用服务器或数据存储设备来实现。由于研发人员只会间接地被连接池属性的标准化所影响，所以有利之处并不明显。然而，通过减少厂商特定设置的属性的数量并用标准化的属性来代替他们，研发人员能更容易地在不同厂商的 jdbc 驱动程式之间进行交换。另外，这些属性还允许管理员非常好地优化连接池，从而使应用程式的性能特点发挥到极致。这些属性如下表所示。 属性名称描述

  maxstatements	连接池能保持打开的语句数目。
  initialpoolsize	当池初始化时能建立的物理连接的数目。
  minpoolsize	池能包含的物理连接的最小数目。
  maxpoolsize	池能包含的物理连接的最大数目。零指没有最大值。
  maxidletime	持续时间，以秒计，指一个闲置的物理连接在被关闭前能在池中停留的时间。零指没有限制。
  propertycycle	间隔时间，以秒计，指连接池在执行其属性策略前能等待的时间。

  
  预备语句池 
  除了改进对连接池的支持以外，目前也能缓冲预备语句了。预备语句允许你用一条常用的 sql 语句然后预编译他，从而在这条语句被多次执行的情况下大幅度地提升性能。在另一个方面，建立一个 preparedstatement 对象会带来一定量的系统开销。所以，在最佳情况下，这条语句的生命周期应该足够长，以补偿他所带来的系统开销。追求性能的研发人员有时候为了延长 preparedstatement 对象的生命周期会不惜扭曲他们的对象模型。jdbc 3.0 让研发人员不再为此担心，因为数据源层目前负责为预备语句进行缓存。 
  清单 3 将示范怎么利用 jdbc 对预备语句池的支持。细心的读者可能会发现清单中的语句和普通 jdbc 2 的代码没什么两样。这是因为语句的缓冲是完全在内部实现的。这就意味着，在 jdbc 3.0 下，你现存的代码能自动利用语句池。但可惜的是，这也意味着你将不能控制哪个预备语句将被缓冲，而只能控制被缓存的语句的数目。 
  清单 3. 缓冲预备语句

  string insert_book_query =
      "insert into booklist " + 
                 "(author, title) " + 
                 "values (?, ?) ";
  connection conn = apooledconnection.getconnection();
  preparedstatement ps = conn.preparestatement(insert_book_query);
  ps.setstring(1, "orwell, george");
  ps.setstring(2, "1984");
  ps.executeupdate();
  ps.close();
  conn.close();
  // ...
  conn = apooledconnection.getconnection();
  // since the connection is from a pooledconnection, the data layer has
  // the option to retrieve this statement from its statement pool,
  // saving the vm from re-compiling the statement again.
  preparedstatement cachedstatement = conn.preparestatemet(insert_book_query);
  // ...

  
  在你的事务中使用 savepoint 
  也许在 jdbc 3.0 中最令人兴奋的附加特点就是 savepoint 了。jdbc 2 中的事务支持让研发人员能控制对数据的并发访问，从而确保持续数据总是保持一致的状态。可惜的是，有时候需要的是对事务多一点的控制，而不是在当前的事务中简单地对每一个改动进行回滚。在 jdbc 3.0 下，你就能通过 savepoint 获得这种控制。savepoint 接口允许你将事务分割为各个逻辑断点，以控制有多少事务需要回滚。图 1 将说明怎么在事务中运用 savepoint。 
  图 1. savepoint 的直观表示 
  
  你或许不是经常需要使用 savepoint。然而，在一种普遍的情况下 savepoint 会发挥作用，那就是你需要作一系列的改动，不过在知道所有的结果之前不能确定应该保留这些改动的哪一部分。清单 4 中的代码示例说明了怎么使用 savepoint 接口。 
  清单 4. 使用 savepoint

  conn.setautocommit(false);
  // set a conservative transaction isolation level.
  conn.settransactionisolation(connection.transaction_serializable);
  statement stmt = conn.createstatement();
  int rows = stmt.executeupdate(
      "insert into authors " +
                   "(first_name, last_name) values " + 
                 "(lewis, carroll)");
  // set a named savepoint.
  savepoint svpt = conn.setsavepoint("newauthor");
  // ...
  rows = stmt.executeupdate(
      "update authors set type = fiction " +
                  "where last_name = carroll");
  // ...
  conn.rollback(svpt);
  // ...
  // the author has been added, but not updated.
  conn.commit();

  
  结论 
  jdbc 3.0 目前正在测试期中，官方发行定在 2001 年下半年。主要的数据库厂商正在致力于提供 jdbc 3.0 的驱动程式，一些早期的测试版驱动程式已能获得。jdbc 3.0 的改动虽然在本质上不是革命性的，但也是个非常重要的进步。通过在现有功能上的扩展，新的 jdbc 规范带给你的是新的策略，以解决你的关系数据库的问题。