JDBC(已阅).doc

JDBC连接JDBC是一种可用于执行SQL语句的Java API。它由一些Java语言编写的类和界面组成。JDBC为数据库开发人员、数据库前台工具开发人员提供了一种标准的应用程序设计接口，使开发人员可以用纯Java语言编写完整的数据库应用程序。Java和JDBC的结合可以让开发人员在开发数据库应用时真正实现很好的移植性。JDBC扩展了Java的能力，如使用Java和JDBC API就可以公布一个Web页，页中带有能访问远端数据库的Applet；或者企业可以通过JDBC让所有的员工（他们可以使用不同的操作系统，如Windows、Machintosh和UNIX）在Internet 上连接到几个全球数据库上，而这几个全球数据库可以是不相同的。程序员可以编写或改写一个程序，然后将它放在服务器上，而每个用户都可以访问服务器得到最新的版本。对于信息服务行业，Java和JDBC提供了一种很好的向外界用户更新信息的方法。简单地说，JDBC能完成以下三件事： 同一个数据库建立连接 向数据库发送SQL语句。 处理数据库返回的结果。JDBC直接调用SQL命令，同时也是构造高层API和数据库开发工具的基础。高层API和数据库开发工具应该是用户界面更加友好，使用更加方便，更易于理解的。当所有这样的API将最终被翻译为像JDBC这样的底层AAPI。SQL语言嵌入Java的预处理器，虽然DBMS已经实现了SQL查询，但JDBC要求SQL语句被当做字符串参数传递给Java程序。而嵌入式SQL预处理器答应程序员将SQL语句混用：Java变量可以在SQL语句中使用来接收或提供数值。然后SQL的预处理器将把这种Java/SQL混用的程序翻译成带有JDBC API的Java程序。JDBC 2.0 API被划分为两部分：JDBC 2.0核心API和JDBC 2.0标准扩展API。核心API在java.sql里面，这时原来的版本就是想了基本的功能。标准扩展API在javax.sql里面，由JDBC 2.0规范新规定的一些接口在这里面。当然，JDBC 2.0也对原来版本的java.sql核心做了一些改动，不过不是很大。原来JDBC1.0的程序可以不加修改地在JDBC2.0上运行。JDBC2.0的扩展API增加了一些数据访问和数据源访问的重大功能。这中间有一些主要用来做企业计算。用JDBC 2.0的新的扩展包，JDBC提供了一个从Java 2平台的通用数据访问的方法。首先，我们来看看JDBC标准扩展的API是怎样和JDBC 2.0结合在一起的。JDBC2.0包括以下两个包。 java.sql包：这个包里面是JDBC2.0的核心API。它包括原来的JDBC API（JDBC 1.0版本），再加上一些新的2.0版本的API。这个包在Java 2 Platform SDK里面提供。 javax.sql包：这里面是JDBC 2.0的标准扩展API。这个包是一个全新的，在Java 2 Platform SDK、Enterprise Edition里面单独提供。JDBC2.0的核心API包括JDBC1.0的API，并在此基础上增加了一些功能，对某些性能做了增强，使Java语言在数据库计算的前端提供了统一的数据访问方法，效率也得到了提高。JDBC是向后兼容的，JDBC1.0的程序可以不加修改地运行在JDBC2.0上。但是，假如程序中的用到了JDBC2.0的新特性，就必须运行在JDBC2.0版本上。概括地说，JDBC核心API的新特性在两个方面做了工作，一个是支持一些新的功能；另一个就是支持SQL3 的数据类型。 在支持新功能方面：包括结果集可以向后滚动，批量地更新数据。另外，还提供了UNICODE字符集的字符流操作。 在支持SQL3的数据类型方面：包括新的SQL3数据类型，增加了对持久性对象的存储。JDBC的新特性在数据存取、交互操作等方面较以往更容易了。例如，数据块的操作能够显著地提高数据库访问的性能。新增加的BLOB、CLOB和数组接口能够使应用程序操作大块的数据类型，而不必使客户端在存储之前进行其他的处理。这样，就显著的提高了内存的使用效率。标准扩展API分为如下几个方面。 DataSource接口：和Java名字目录服务（JNDI）一起工作的数据源接口。 Connection pooling（连接池）：可以重复使用连接，而不是对每个请求都使用一个新的连接。 Distrbute transaction（分布式的事务）：在一个事务中涉及多个数据库服务器 Rowsets：Java Bean组件包含结果集，主要用来将数据传给瘦客户，或者提供一个可以滚动的结果集。下面具体介绍：1、 DataSource接口是一个更好的连接数据源的方法JDBC1.0原来是用DriverManager类来产生一个谁数据源的连接。一个DataSource对象代表了一个真正的数据源。根据数据源DataSource的实现方法，数据源既可以是关系数据库，也可以是电子表格，还可以是一个表格形式的文件。当一个DataSource对象注册到名字服务中，应用程序就可以通过名字服务获得DataSource对象，并用他来产生一个与DataSource代表的数据源之间的连接。关于数据源的信息和如何定位数据源，例如，数据库服务器的名字、在哪台机器上、端口号等，都包含在DataSource对象的属性中。这样，对应用程序的设计就更加方便，因为并不需要硬性地把驱动的名字固定到程序中。通常，驱动名字中都包含了驱动提供商的名字，而在DriverManager类中通常是这么做的。如果数据源要移植到另一个数据库驱动中，代码也很容易修改。所需要做的修改只是更改DataSource的相关属性，而使用DataSource对象的代码不需要做任何改动。由系统管理员或者有相应权限的人来配置DataSource对象，配置DataSource时，包括设定DataSource的属性，然后将它注册到JNDI名字服务器中去，在注册DataSource对象的过程中，系统管理员需要把DataSource对象和一个逻辑名字关联起来。名字可以是任意的，通常取能代表数据源且容易记住的名字。在下面的例子中，名字起为：InventoryDB，按照惯例，逻辑名字通常都在jdbc的子上下文中。这样，逻辑名字的全名就是：jdbc/InventoryDB。一旦配置好了数据源对象，应用程序设计者就可以用它来产生一个与数据源的连接，下面的代码片段示例了如何使用JNDI上下文获得一个数据源对象，然后如何用数据源对象产生一个与数据源的连接。开始的两行用的是JNDI API，第三行用的才是JDBC的API。Context ctx = new InitialContext();DataSource ds = (DataSource)ctx.lookup(“jdbc/InventoryDB”);Connection con = ds.getConnection(“myPassword”,”myUserName”);在一个基本的DataSource实现中，DataSource.getConnection方法返回的Connection对象和用DriverManager.getConnection方法返回的Connection对象是一样的。因为DataSource提供的方便性，我们推荐使用DataSource对象来得到一个Connection对象。我们希望所有的基于JDBC2.0技术的数据库驱动都包含一个基本的DataSource的实现，这样就很容易在应用程序中使用它。对于普通的应用程序设计者，是否使用DataSource对象只是一个选择问题。但是，对于那些需要用连接池或者分布式事务的应用程序设计者来说，就必须使用DataSource对象来获得Connection（其中的原因我们在下面会提到）。2、 Connection pooling（连接池）连接池是这么一种机制：当应用程序关闭一个Connection的时候，这个连接被回收，而不是被破坏，因为建立一个连接是很浪费资源的操作。如果能把回收的操作连接重新利用，会减少新创建连接的数目，从而显著地提高运行的性能。假设应用程序需要建立到一个名字为EmployeeDB的DataSource的连接，使用连接池得到连接的代码如下：Context ctx = new InitialContext();DataSource ds = (DataSource)ctx.lookup(“jdbc/EmployeeDB”);Connection con = ds.getConnection(“myPassword”,”myUserName”);除了逻辑名字以外，我们发现其代码和上面所举例子的代码是一样的。逻辑名字不同，就可以连接到不同的数据库。DataSource对象的getConnection方法返回的Connection是否是一个连接池中的连接，这个连接也是可以重复利用的。是否使用一个连接池获得一个连接，在应用程序的代码上是看不出不同的。在使用这个Connection连接上也没有什么不一样的地方，唯一不同的是在Java的finally语句块中来关闭一个连接。在finally中关闭连接是一个好的编程习惯。这样，即使方法抛出异常，Connection也会被关闭并回收到连接池中。代码如下所示：trycatch()finallyif(con!=null) con.close()3、 分布式事务获得一个用来支持分布式事务的连接与获得连接池中的连接是很相似的。同样，不同之处在于DataSource实现上的不同，而不是在应用程序中获得连接的方式有什么不同。假设DataSource的实现可以与分布式事务的中间层服务器一起工作得到连接的代码如下所示：Context ctx = new InitialContext();DataSource ds = (DataSource)ctx.lookup(“jdbc/EmployeeDB”);Connection con = ds.getConnection(“myPassword”,”myUserName”);由于性能上的原因，如果一个DataSource能够支持分布式的事务，它同样也可以支持连接池管理。从应用程序设计者的观点来看，是否支持分布式的事务的连接对程序本身来说没什么不同，唯一的不同是在事务的边界上（开始一个事务的地方和结束一个事务的地方），开始一个事务或者结束一个事务都是由事务服务器来控制的。应用程序不应该做任何可能妨碍服务的事情。应用程序不能够直接调用事务提交（commit）或者回滚（rollback）操作，也不能使用事务的自动提交模式（在数据库操作完成的时候自动调用commit或者rollback）。对于通常的Connection来说，默认的是auto-commit模式，而对于支持分布式事务的Connection来说，默认的不是auto-commit模式。注意，即使Connection是支持事务的，它也可以用于没有事务的情况。关于事务边界的限制，只在针对分布式事务的情况下才成立。4、 结果集结果集对象是一行行数据的容器。根据其目的，可以通过多种方法实现。RowSet及其相关的接口与JDBC 2.0的标准扩展API有点不同，它们并不是驱动的一部分，RowSet是在驱动的上一层实现的，可以由其他任何人来实现它们。任何类型的RowSet都实现了RowSet接口，RowSet接口扩展了ResultSet接口。这样RowSet对象就有了ResultSet对象所有的功能，能够通过getXXX方法得到数据库中的某列值，通过updateXXX方法可以修改某列值，可以移动光标，使当前行变为另一行。当然，我们更感兴趣的是RowSet接口提供的新功能。作为一个Java Bean组件，RowSet对象可以增加或者删除一个listener（监听者），可以get或者set其属性值，在这些属性中，有一个是字符串，表示一个对数据库的Query请求，RowSet接口定义了设定参数的方法，也提供了执行这个请求的方法。这意味着RowSet对象能够执行查询请求，可以根据它产生的结果集进行计算。同样，RowSet也可以根据任何表格数据源进行计算。所以，他不局限于关系数据库。从数据源得到数据之后，RowSet对象可以和数据源断开连接，RowSet也可以被序列化。这样，RowSet就可以通过网络传递给瘦客户端。RowSet可以被重新连接到数据源，这样，所做的修改就可以存回到数据源中去。如果产生了一个listener，当RowSet 的当前行移动或数据被修改的时候，监听者就会收到通知。例如，图形用户界面组件可以注册成为监听者，当RowSet更改的时候，图像用户界面接到通知，就可以修改界面，来符合它所表示的RowSet。根据不同的需要，RowSet接口可以通过多种方法来实现。与Cached RowSet类不一样的是，JDBC RowSet类总是保持和数据源的连接。相当于在ResultSet外围加了一层，使基于JDBC技术的驱动看起来像一个简单的Java Bean组件一样。preparedStatement类、CallableStatement类和Statement（1） Prepared（准备好的、精致的），从这里可以知道PreparedStatement是预先编译的语句，而Statement则不是预先编译的。PreparedStatement继承于Statement，通常JDBC实现过程中，PrepareStatement最终还是通过Statement的相关方法来执行SQL的（可以做少量优化），其最主要的优势在于可以减少SQL的编译错误（在JDBC中的就可以捕获部分异常而不是由数据库服务器执行时返回错误代码），增加SQL安全性（减少SQL注入的机会）。（2） PreparedStatement中执行的SQL语句中是可以带参数的，而Statement则不可以。比如：PreparedStatement psmt=con.prepareStatement(“UPDATE EMPLOYEES SET SALARY =? WHERE ID=?”);Psmt.setBigDecimal(1,1000.00);Psmt.setInt(2,1111);Psmt.executeUpdate();（3） 对于数据库来说的，单个PreparedStatement因为还需要参数代入过程，所以比单个Statement执行速度慢是很正常的。但是对于一个真实的应用来说，单个请求执行速度快几十毫秒还是慢几十毫秒，根本无关紧要。当处理批量SQL语句时，这个时候就可以体现PreparedStatement的优势，由于采用Cache机制，则预先编译的语句就会放在Cache中，下次执行相同的SQL语句时，则可以直接从Cache块中取出来。例如，