Java事务处理全解析(四)—— 成功的案例(自己实现一个线程安全的TransactionManager)
在本系列的上一篇文章中我们讲到,要实现在同一个事务中使用相同的Connection对象,我们可以通过传递Connection对象的方式达到共享的目的,但是这种做法是丑陋的。在本篇文章中,我们将引入另外一种机制(ConnectionHolder)来完成事务管理。
ConnectionHolder的工作机制是:我们将Connection对象放在一个全局公用的地方,然后在不同的操作中都从这个地方取得Connection,从而完成Connection共享的目的,这也是一种ServiceLocator模式,有点像JNDI。定义一个ConnectionHolder类如下:

package davenkin.step3_connection_holder; import javax.sql.DataSource;
import java.sql.Connection;
import java.sql.SQLException;
import java.util.HashMap;
import java.util.Map; public class ConnectionHolder
{
private Map<DataSource, Connection> connectionMap = new HashMap<DataSource, Connection>(); public Connection getConnection(DataSource dataSource) throws SQLException
{
Connection connection = connectionMap.get(dataSource);
if (connection == null || connection.isClosed())
{
connection = dataSource.getConnection();
connectionMap.put(dataSource, connection);
} return connection;
} public void removeConnection(DataSource dataSource)
{
connectionMap.remove(dataSource);
}
}

从ConnectionHolder类中可以看出,我们维护了一个键为DataSource、值为Connection的Map,这主要用于使ConnectionHolder可以服务多个DataSource。在调用getConnection方法时传入了一个DataSource对象,如果Map里面已经存在该DataSource对应的Connection,则直接返回该Connection,否则,调用DataSource的getConnection方法获得一个新的Connection,再将其加入到Map中,最后返回该Connection。这样在同一个事务过程中,我们先后从ConnectionHolder中取得的Connection是相同的,除非在中途我们调用了ConnectionHolder的removeConnection方法将当前Connection移除掉或者调用了Connection.close()将Connection关闭,然后在后续的操作中再次调用ConnectionHolder的getConnection方法,此时返回的则是一个新的Connection对象,从而导致事务处理失败,你应该不会做出这种中途移除或关闭Connection的事情。
然而,虽然我们不会自己手动地在中途移除或者关闭Conncetion对象(当然,在事务处理末尾我们应该关闭Conncetion),我们却无法阻止其他线程这么做。比如,ConnectionHolder类是可以在多个线程中同时使用的,并且这些线程使用了同一个DataSource,其中一个线程使用完Connection后便将其关闭,而此时另外一个线程正试图使用这个Connection,问题就出来了。因此,上面的ConnectionHolder不是线程安全的。
为了获得线程安全的ConnectionHolder类,我们可以引入Java提供的ThreadLocal类,该类保证一个类的实例变量在各个线程中都有一份单独的拷贝,从而不会影响其他线程中的实例变量。定义一个SingleThreadConnectionHolder类如下:

package davenkin.step3_connection_holder; import javax.sql.DataSource;
import java.sql.Connection;
import java.sql.SQLException; public class SingleThreadConnectionHolder
{
private static ThreadLocal<ConnectionHolder> localConnectionHolder = new ThreadLocal<ConnectionHolder>(); public static Connection getConnection(DataSource dataSource) throws SQLException
{
return getConnectionHolder().getConnection(dataSource);
} public static void removeConnection(DataSource dataSource)
{
getConnectionHolder().removeConnection(dataSource);
} private static ConnectionHolder getConnectionHolder()
{
ConnectionHolder connectionHolder = localConnectionHolder.get();
if (connectionHolder == null)
{
connectionHolder = new ConnectionHolder();
localConnectionHolder.set(connectionHolder);
}
return connectionHolder;
} }

有了一个线程安全的SingleThreadConnectionHolder类,我们便可以在service层和各个DAO中使用该类来获取Connection对象:
Connection connection = SingleThreadConnectionHolder.getConnection(dataSource);
当然,此时我们需要传入一个DataSource,这个DataSource可以作为DAO类的实例变量存在,所以我们不用像上一篇文章那样将Connection对象直接传给DAO的方法。这里你可能要问,既然可以将DataSource作为实例变量,那么在上一篇文章中,为什么不可以将Connection也作为实例变量呢,这样不就不会造成丑陋的API了吗?原因在于:将Connection对象作为实例变量同样会带来线程安全问题,当多个线程同时使用同一个DAO类时,一个线程关闭了Connection而另一个正在使用,这样的问题和上面讲到的ConnectionHolder的线程安全问题一样。
关于Bank DAO和Insurance DAO类的源代码这里就不列出了,他们和上篇文章只是获得Connection对象的方法不一样而已,你可以参考github源代码。
接下来,我们再来看看TransactionManager类,在上几篇文章中,我们都是在service类中直接写和事务处理相关的代码,而更好的方式是声明一个TransactionManger类将事务处理相关工作集中管理:

package davenkin.step3_connection_holder; import javax.sql.DataSource;
import java.sql.Connection;
import java.sql.SQLException; public class TransactionManager
{
private DataSource dataSource; public TransactionManager(DataSource dataSource)
{
this.dataSource = dataSource;
} public final void start() throws SQLException
{
Connection connection = getConnection();
connection.setAutoCommit(false);
} public final void commit() throws SQLException
{
Connection connection = getConnection();
connection.commit();
} public final void rollback()
{
Connection connection = null;
try
{
connection = getConnection();
connection.rollback(); } catch (SQLException e)
{
throw new RuntimeException("Couldn't rollback on connection[" + connection + "].", e);
}
} public final void close()
{
Connection connection = null;
try
{
connection = getConnection();
connection.setAutoCommit(true);
connection.setReadOnly(false);
connection.close();
SingleThreadConnectionHolder.removeConnection(dataSource);
} catch (SQLException e)
{
throw new RuntimeException("Couldn't close connection[" + connection + "].", e);
}
} private Connection getConnection() throws SQLException
{
return SingleThreadConnectionHolder.getConnection(dataSource);
}
}

可以看出,TransactionManager对象也维护了一个DataSource实例变量,并且也是通过SingleThreadConnectionHolder来获取Connection对象的。然后我们在service类中使用该TransactionManager:

package davenkin.step3_connection_holder; import davenkin.BankService;
import javax.sql.DataSource; public class ConnectionHolderBankService implements BankService
{
private TransactionManager transactionManager;
private ConnectionHolderBankDao connectionHolderBankDao;
private ConnectionHolderInsuranceDao connectionHolderInsuranceDao; public ConnectionHolderBankService(DataSource dataSource)
{
transactionManager = new TransactionManager(dataSource);
connectionHolderBankDao = new ConnectionHolderBankDao(dataSource);
connectionHolderInsuranceDao = new ConnectionHolderInsuranceDao(dataSource); } public void transfer(int fromId, int toId, int amount)
{
try
{
transactionManager.start();
connectionHolderBankDao.withdraw(fromId, amount);
connectionHolderInsuranceDao.deposit(toId, amount);
transactionManager.commit();
} catch (Exception e)
{
transactionManager.rollback();
} finally
{
transactionManager.close();
}
}
}

在ConnectionHolderBankService中,我们使用TransactionManager来管理事务,由于TransactionManger和两个DAO类都是使用SingleThreadConnectionHolder来获取Connection,故他们在整个事务处理过程中使用了相同的Connection对象,事务处理成功。我们也可以看到,在两个DAO的withdraw和deposit方法没有接受和业务无关的对象,消除了API污染;另外,使用TransactionManager来管理事务,使Service层代码也变简洁了。
在下一篇文章中,我们将讲到使用Template模式来完成事务处理。
Java事务处理全解析(四)—— 成功的案例(自己实现一个线程安全的TransactionManager)的更多相关文章
- Java事务处理全解析(一)——Java事务处理的基本问题
Java中的事务处理有多简单?在使用EJB时,事务在我们几乎察觉不到的情况下发挥着作用:而在使用Spring时,也只需要配置一个TransactionManager,然后在需要事务的方法上加上Tran ...
- Java事务处理全解析(二)——失败的案例
在本系列的上一篇文章中,我们讲到了Java事务处理的基本问题,并且讲到了Service层和DAO层,在本篇文章中,我们将以BankService为例学习一个事务处理失败的案例. BankService ...
- Java事务处理全解析(七)—— 像Spring一样使用Transactional注解(Annotation)
在本系列的上一篇文章中,我们讲到了使用动态代理的方式完成事务处理,这种方式将service层的所有public方法都加入到事务中,这显然不是我们需要的,需要代理的只是那些需要操作数据库的方法.在本篇中 ...
- Java事务处理全解析(六)—— 使用动态代理(Dynamic Proxy)完成事务
在本系列的上一篇文章中,我们讲到了使用Template模式进行事务管理,这固然是一种很好的方法,但是不那么完美的地方在于我们依然需要在service层中编写和事务处理相关的代码,即我们需要在servi ...
- Java事务处理全解析(三)——丑陋的案例
在本系列的上一篇文章中,我们看到了一个典型的事务处理失败的案例,其主要原因在于,service层和各个DAO所使用的Connection是不一样的,而JDBC中事务处理的作用对象正是Connectio ...
- Java事务处理全解析(五)—— Template模式
在本系列的上一篇文章中,我们讲到了使用TransactionManger和ConnectionHolder完成线程安全的事务管理,在本篇中,我们将在此基础上引入Template模式进行事务管理. Te ...
- Java事务处理全解析(八)——分布式事务入门例子(Spring+JTA+Atomikos+Hibernate+JMS)
在本系列先前的文章中,我们主要讲解了JDBC对本地事务的处理,本篇文章将讲到一个分布式事务的例子. 请通过以下方式下载github源代码: git clone https://github.com/d ...
- java事务处理全解析
http://blog.csdn.net/huilangeliuxin/article/details/43446177
- 《Java面试全解析》505道面试题详解
<Java面试全解析>是我在 GitChat 发布的一门电子书,全书总共有 15 万字和 505 道 Java 面试题解析,目前来说应该是最实用和最全的 Java 面试题解析了. 我本人是 ...
随机推荐
- vuex是啥
vuex是一个状态管理工具. vuex store与一个简单的全局变量的区别是: 1.vuex stores 是响应式的,当组件改变state时,它能响应并高效地更新state. 2.state不能被 ...
- AC自动机最好讲解
http://www.cs.uku.fi/~kilpelai/BSA05/lectures/slides04.pdf
- Linux 安装图形界面及远程连接
#可查询哪些组件是否已经安装(可用来对照组件名称) yum grouplist yum groupinstall 'X Window System' -y #安装GNOME桌面环境 yum group ...
- .htaccess保护目录与文件
一般来说很多虚拟主机预设是没有开启保护网站主机目录下的文件,其实很危险的,假若你的目录下忘记放置index文件,那很可能您目录就被看光,一个不小心很可能重要资料就被拿走,这是蛮严重的一件事情.如果是L ...
- linux命令每日一练习-rmdir mv
rmdir 删除一个空的文件夹,当目标文件夹非空的时候不能删除 mv 移动文件或目录 mv source target mv -i *** *** 如果目标文件存在则询问是否覆盖 mv -f *** ...
- rails之 Migrations (转)
1.简介 在rails中用migration可以很方便的管理数据库的结构.可以创建数据库,创建表,删除表,添加字段,删除字段,整理数据. migration就是一系列的class,这些类都继承了Act ...
- 大量无线键盘存在KeySniffer漏洞-可嗅探用户输入的内容
几美元的一根天线.一个无线发射器,还有几行Python代码,有了这些,黑客就可以在几十米开外主动地记录下你的用户名.密码.信用卡.你写的稿子,总之就是你用无线键盘输入的任何东西. 黑客所利用的是一种无 ...
- css3 倒影
说起倒影效果,在传统网页中,我们只能使用photoshop进行事先将倒影设计好,然后导入到网页中,这样不但耗费资源,也阻碍了开发的效率.而 css3新增了Reflections板块,css Refl ...
- 三部曲二(基本算法、动态规划、搜索)-1006-The Same Game
The Same Game Time Limit: 1000MS Memory Limit: 10000K Total Submissions: 4585 Accepted: 1699 Des ...
- Lua协程
协作例程 1.同一时刻仅一个例程在运行 2.执行权让渡和恢复[栈]