`
tigers20010
  • 浏览: 46773 次
  • 性别: Icon_minigender_1
  • 来自: 深圳
社区版块
存档分类
最新评论

2009-12-02传智播客 数据库——JDBC开发 连接池与事务(转载)

    博客分类:
  • JDBC
阅读更多
Today is JDBC高级部分,课程的主要内容有连接池与事务。这都是在应用开发中比较常用,比较重要的。

一、使用配置文件优化JDBCUtil,使用工厂模式隔离DAO层:

昨天有说过将对数据库获取连接和释放的操作单封装到一个类中,如:

import java.sql.*;
import cn.itcast.cc.exception.JDBCUtilException;

/**
* JDBC工具类
*
* @author Administrator
*
*/
public class JDBCUtil {
// 连接数据库时所需要的参数
private static String url = "jdbc:mysql://localhost:3306/jdbc";
private static String username = "root";
private static String password = "root";
// 类被加载时就加载驱动
static {
try {
Class.forName("com.mysql.jdbc.Driver");
} catch (ClassNotFoundException e) {
e.printStackTrace();
}
}

// 获取连接
public static Connection getConnection() throws JDBCUtilException {
try {
return DriverManager.getConnection(url, username, password);
} catch (SQLException e) {
throw new JDBCUtilException(e);
}
}

// 释放连接等资源,下面是一种健康的释放方式
public static void release(ResultSet rs, Statement sta, Connection conn)
throws JDBCUtilException {
if (rs != null) {
try {
rs.close();
} catch (SQLException e) {
throw new JDBCUtilException(e);
}
rs = null;
}

if (sta != null) {
try {
sta.close();
} catch (SQLException e) {
throw new JDBCUtilException(e);
}
sta = null;
}

if (conn != null) {
try {
conn.close();
} catch (SQLException e) {
throw new JDBCUtilException(e);
}
conn = null;
}
}
}
从上面我们看到其中装载数据库驱动和获取数据库连接的代码: Class.forName("com.mysql.jdbc.Driver");

DriverManager.getConnection(url, username, password);



我们使用了固定的url,它是一个成员。在以后的开发中,如果要使用其他的数据库或者数据库的用户名密码被改变了,我们还需要手动的修改上边的代码,重新编译。这是一种不良的设计方法,为了使我们的代码与数据库分离,我们可以将这些参数配置到配置文件中。这样在需要使用时去读取配置文件中的对应值即可。以后换数据库或更改了用户名,直接修改一下配置文件即可。

昨天有提到过DAO层,DAO层专门用于处理对数据库的CURD操作等,比如,添加用户、查找用户、修改用户、删除用户,我们可以把这些操作封装到一个类中(UserDao.java),它所处位置就是DAO层。比如,用于处理用户注册的Servlet,在这个Servlet中直接实例化一个UserDao对象。然后调用userDaoObj.add(userbean);方法即可实现用户的注册。

如果我想换一种数据存储方式,比如配置文件,我只将用户信息保存在配置文件中。这样我就需要修改UserDao.java,但有时又需要UserDao.java这个功能类怎么办?我只能重新创建一个专门处理配置文件数据的类(UserDaoPro.java)。这样我又需要修改Servlet中的代码,将实例化UserDao的代码修改为实例化UserDaoPro对象。那UserDaoPro与UserDao的接口是不是相同的呢?如果不相同麻烦就大了,JAVA是提倡使用接口编程的,就是为了实现接口的统一化。

可见,上面的这种实现方式是存在问题的。即使接口统一,我们还需要修改Servlet中的代码。此时工厂模式派上了用场,还记得工厂模式吧!是这样的:

1.定义一个UserDao接口,统一对用户操作的接口。

2.定义一个UserDaoFactory的工厂类,专门生产UserDao对象。

3. UserDaoFactory工厂从配置文件中读取实现了UserDao接口的类名称。使用此类生产产品——UserDao对象。

4.在Servlet中使用UserDaoFactory工厂来创建需要的UserDao对象。

这样就实现了DAO层与Servlet的完全分离!完美!

二、数据库连接池:

每当有一个新的连接发生时,数据库就需要创建一个Connection对象来处理连接。访问结束后,Connection对象被释放。数据库创建一个Connection对象,是十分耗时且消耗较大的服务器资源。试想,如果有500个用户同时访问数据库,数据库同时创建500个Connection将会是什么样子!因此,连接池这一技术诞生了。

连接池,在服务器加载WEB应用后。WEB应用会自动创建一个连接池,池中包含多个Connection对象。每当有新的连接请求时,便从这个池中拿出一个Connection对象用于处理连接,使用完成后,便还回给这个池子。下面代码为连接池的实现原理:

import java.io.*;
import java.lang.reflect.*;
import java.sql.*;
import java.util.*;
import javax.sql.DataSource;

/**
* 自己编写的简单连接池类,单例模式实现。
*
* @author Administrator
*
*/
public class JDBCUtil implements DataSource {
private static LinkedList<Connection> conns = new LinkedList<Connection>();
private static JDBCUtil myjdbcutil = new JDBCUtil();

private JDBCUtil() {
// 取配置文件
InputStream in = JDBCUtil.class.getClassLoader().getResourceAsStream(
"cn/itcast/cc/db/myjdbc.properties");
// 装载配置文件
Properties pro = new Properties();
try {
pro.load(in);
} catch (IOException e) {
e.printStackTrace();
}
// 取出配置项
String driver = pro.getProperty("driverClassName");
String url = pro.getProperty("url");
String username = pro.getProperty("username");
String password = pro.getProperty("password");
int initialSize = Integer.parseInt(pro.getProperty("initialSize"));
// 加载驱动,填充连接池
try {
// 常用的数据库,驱动类被加载时,都会自已加载驱动。
Class.forName(driver);
for (int i = 0; i < initialSize; i++) {
conns.add(DriverManager.getConnection(url, username, password));
}
} catch (Exception e) {
e.printStackTrace();
}
}

// 返回单例的实例
public static JDBCUtil getInstance() {
return myjdbcutil;
}

public Connection getConnection() throws SQLException {
if (conns.size() > 0) {
final Connection conn = conns.pop();
// 此处需要使用动态代理技术,因为返回的Connection对象在关闭时需要被收回到LinkedList中。
// 动态代理,增强Connection.colse()方法,将它回收到LinkedList中。但不销毁!
return (Connection) Proxy.newProxyInstance(JDBCUtil.class
.getClassLoader(), conn.getClass().getInterfaces(),
new InvocationHandler() {

public Object invoke(Object proxy, Method method,
Object[] args) throws Throwable {
// 如果是close方法,则将conn回收到List中。
if (method.getName().equals("close")) {
conns.push(conn);
return null;
}
return method.invoke(conn, args);
}
});
}
throw new RuntimeException("服务器忙,请稍后连接!");
}
}
有很多服务器为用户提供了DataSource(数据源)的实现。DataSource中包含了连接池的实现。也有一些第三方组织单独提供了连接池的实现:DBCP、C3P0。所以,在以后的开发中,我们可以直接使用这些资源。

著名的DBCP比较常用,使用DBCP必须引入Commons-dbcp.jar和Commons-pool.jar。Tomcat中的连接池也是使用DBCP实现的。DBCP的使用非常简单:

import java.io.InputStream;
import java.sql.*;
import java.util.Properties;
import javax.sql.DataSource;
import org.apache.commons.dbcp.BasicDataSourceFactory;

public class DBCPUtil {
private static DataSource ds = null;
static {
try {
// 取配置文件
InputStream in = JDBCUtil.class.getClassLoader()
.getResourceAsStream(
"cn/itcast/cc/db/dbcpconfig.properties");
// 装载配置文件
Properties pro = new Properties();
pro.load(in);
// 创建数据源
ds = BasicDataSourceFactory.createDataSource(pro);
} catch (Exception e) {
e.printStackTrace();
}
}

// 获取连接
public static Connection getConnection() throws SQLException {
return ds.getConnection();
}
}


其中的配置文件“dbcpconfig.properties”: #连接设置

#驱动器

driverClassName=com.mysql.jdbc.Driver

#数据库连接URL

url=jdbc:mysql://localhost:3306/jdbc

#数据库用户名

username=root

#数据库密码

password=root

#初始连接池数量

initialSize=10

#最大连接数量

maxActive=50

#最大空闲连接

maxIdle=20

#最小空闲连接

minIdle=5

#超时等待时间以毫秒为单位 6000毫秒/1000等于60秒

maxWait=60000

#JDBC驱动建立连接时附带的连接属性属性的格式必须为这样:[属性名=property;]

#注意:"user" 与 "password" 两个属性会被明确地传递,因此这里不需要包含他们。

connectionProperties=useUnicode=true;characterEncoding=UTF8

#指定由连接池所创建的连接的自动提交(auto-commit)状态。

defaultAutoCommit=true

#driver default 指定由连接池所创建的连接的只读(read-only)状态。

#如果没有设置该值,则“setReadOnly”方法将不被调用。(某些驱动并不支持只读模式,如:Informix)

defaultReadOnly=

#driver default 指定由连接池所创建的连接的事务级别(TransactionIsolation)。

#可用值为下列之一:(详情可见javadoc。)NONE,READ_UNCOMMITTED, READ_COMMITTED, REPEATABLE_READ, SERIALIZABLE

defaultTransactionIsolation=READ_UNCOMMITTED



上面是直接使用Apache提供的DBCP实现的连接池,接下来看一下使用JNDI技术在Tomcat中配置连接池,在Tomcat服务的conf\context.xml文件中添加: <Context>

<Resource name="jdbc/datasource" auth="Container"

type="javax.sql.DataSource" username="root" password="root"

driverClassName="com.mysql.jdbc.Driver"

url="jdbc:mysql://localhost:3306/jdbc"

maxActive="8" maxIdle="4"/>

</Context>



Name: 对象在JNDI容器中的名称。

Auth:所使用的容器。

Type:对象类型。

Username:数据库用户名。

Password:数据库密码。

driverClassName:数据库驱动类。

url:连接数据库的URL。

maxActive:最大连接数。

maxIdle:最大空闲连接数。

注意其中的数据库驱动,对应的jar包必须放置到Tomcat目录下的lib目录中。这样服务器才能找得到。

在WEB应用中获取数据库连接的代码: // 初始化JNDI环境

Context initCtx = new InitialContext();

// 获取JNDI容器

Context envCtx = (Context) initCtx.lookup("java:comp/env");

// 获取数据源

DataSource dataSource = (DataSource)envCtx.lookup("jdbc/datasource");

// 获取数据库连接

dataSource.getConnection();



JNDI是一个对象容器,服务器根据配置文件提供的信息。创建这些对象,并按照指定的名称保存在容器中。WEB应用,无论在何处都可以根据名称获取在JNDI容器中的对象。

三、数据库事务管理:

什么是事务?老方有这样的面试题。事务指逻辑上的一组操作,这组操作要不全部生效,要不全部失效。在控制台中操作事务的命令: start transaction 开启事务

Rollback 回滚事务

Commit 提交事务

set transction isolation level 设置事务隔离级别

select @@tx_isolation 查询当前事务隔离级别



事务的特性(ACID),这在面试中是比较常见的。老方一再强调,一定要记下来!OK,让我们看一看。

事务的原子性(Automicity),它更像是事务的定义。就是逻辑上的一组操作,不可分割,要么全部生效,要么全部失效。

事务的一致性(Consistency),老方的PPT有中说:事务必须使数据库从一个一致性状态变换到另外一个一致性状态。比如,银行转账,A-B。A账户中减少100元,B帐户中增加一百元。这看起来比较好理解,但让我有点疑问的是,如果从数据库中删除一个用户呢?难道不用事务处理吗?所以我对这个一致性的理解除了老方说的,还有只要事务处理符合正确的逻辑,就是一致性。

隔离性(Isolation),如果多个用户同时访问数据库,同时访问一张表。这样会造成一些访问错误,所以有了隔离性这一定义。将多个并发事务之间要相互隔离。

持久性(Durability),事务一旦被提交,它对数据库中数据的改变是永久性的,无论其他操作或数据库故障不会对它有任何影响。

在JDBC中使用事务的语句: // 开启事务

conn.setAutoCommit(false);

// 回滚事务

conn.rollback();

// 提交事务

conn.commit();

// ...

// 设置保存点

sp = conn.setSavepoint();

// 回滚到指定保存点

conn.rollback(sp);



方老师使用了一个经典的案例,来讲解事务处理——银行转账系统!

例,用户A转账10000元给用户B。应该是A账户中减少10000元,B账户中增加10000元。那么在A提交了10000元后,数据库发生问题(比如断电),那B帐户增加10000元的语句还没有执行。使用事务可以很好解决这一问题:

1. 开启事务

2. A帐户减少10000元

3. 中间发生错误,回滚事务

4. B帐户增加10000元

5. 提交事务

OK,在上同这一过程中,如果没有执行到第5步。数据库的内容就不会发生改变。在此有必要解释一下回滚事务,回滚事务在提交事务后执行没有什么效果,回滚事务在提交事务之前执行,会擦除在开启事务之后执行的SQL语句。

上面是针对单一事务进行的处理,在并发事务中会遇到一些问题。设置事务的隔离级别可以很好的解决这一问题。

首先我们来看一下并发事务容易产生的问题:

脏读:

例,用户A账户减少10000元,用户B账户增加了10000元,但A还没有提交事务。此时,B去查询它的账户发现A已经给自己转账了10000元。然后,A回滚了事务。B被A给骗了,这就是脏读,B读到的是未提交的数据。我虽对数据库事务的实现原理不了解(事务是通过日志处理的),我打个比方就更好理解这一原因了。数据库对所有用户维护了一个虚表,在开启事务中,提交事务前对数据的修改,都是修改的虚表,用户查询的也是虚表的内容,当执行了提交事务操作后,将虚表中被修改的内容保存到数据库。实际技术细节就不深入了!

不可重复读:

例,用户A原账户内容为100万元,此时银行将数据显示到电脑屏幕和保存到文件中。银行工作人员在电脑屏幕上看到的是100万元,但此时,用户A向账户里又存了100万元。结果保存到文件的是200万元。到是100万元还是200万元?工作人员有些迷惑。与脏读相反的是,脏读是读取了前一事务未提交的数据,不可重复读读取的是前一事务提交了的事务。注意,不可重复读针对的是某一记录!

虚读:

例,银行要统计A的报表。A的账户中有200万元,屏幕上报表显示的总额是200万元,此时,用户A向账户中又存入了100万元。报表打印出来的总额就是300万元。工作人员一对比,到底哪个是正确的?注意,虚读针对的是整个表。

不可重复读和虚读,有点难理解。这看起来不是什么问题,如果发生这一问题,工作人员就刷新一下表呗!如果工作人员处理的是1万个用户的报表,同时不幸运的是这1万个用户都发生了虚读的问题。那工作人员能受了吗?你可能还会说那就以打印的报表为准呗!问题是,可能屏幕上的那个才是正确的,这样就要重新打印报表。所以为了使问题得以简单的解决,事务的隔离性发挥了它的作用!

处理上边的三种并发事务产生的问题,数据库定义了四种隔离级别: Serializable:可避免脏读、不可重复读、虚读情况的发生。

Repeatable read:可避免脏读、不可重复读情况的发生。

Read committed:可避免脏读情况发生。

Read uncommitted:最低级别,以上情况均无法保证。



Serializable,最高安全级别。设置了此级别,当一个事务访问了某一表时,此表就会被封死。其他事务对此表的访问就会被挂起,直到上一事务提交后才执行一个事务。OK,这看起来十分容易理解。

Repeatable read,让我再小深入一下,当每个事务线程访问同一表时,数据库针对每个线程维护了一张虚拟表。此时各线程看到的都是原始的数据内容,对表数据的修改相互不发生影响,即使事务被提交了。数据库可能为每个线程维护了一张虚拟表吗?当然不可以,我想这只是为了便于理解。技术细节不深入研究!

Read committed,数据库对每个用户的查询显示的都是原始内容(真实内容)。如果某些用户对此表的事务没有提交就不会影响原始内容。所以其他用户查看到的都是原始内容或提交了的数据内容。

Read uncommitted,这个就不多说了。

今天的内容也就事务的隔离性有些难度吧!一般也不会去用那最高安全级别,这一级别在银行中比较常用。

正如老方所说,是不是感觉越学越简单了!确实如此,我想大家应该也对此有感觉。不知不觉明天又休息了!

加油!

分享到:
评论

相关推荐

Global site tag (gtag.js) - Google Analytics