Java事务处理全解析(三)—— 丑陋的案例
来源:互联网 发布:炫云客户端知乎 编辑:程序博客网 时间:2024/06/02 15:56
在本系列的上一篇文章中,我们看到了一个典型的事务处理失败的案例,其主要原因在于,service层和各个DAO所使用的Connection是不一样的,而JDBC中事务处理的作用对象正是Connection对象,所以不同DAO中的操作不在同一个事务里面,从而导致事务失败。从中我们得出了教训:要避免这种失败,我们可以使所有操作共享一个Connection对象,这样应该就没有问题了。
请通过以下方式下载本系列文章的github源代码:
Git clone https://github.com/davenkin/java_transaction_workshop.git
在本篇文章中,我们将看到一个成功的,但是丑陋的事务处理方案,它的基本思路是:在service层创建Connection对象,再将该Connection传给各个DAO类,这样就完成了Connection共享的目的。
修改两个DAO类,使他们都接受一个Connection对象,定义UglyBankDao类如下:
使用同样的方法,定义UglyInsuranceDao类:
然后修改Service类,在UglyBankService类的transfer方法中,首先创建一个Connection对象,然后在将该对象依次传给UglyBankDao的withdraw方法和UglyInsuranceDao类的deposit方法,这样service层和DAO层使用相同的Connection对象。定义UglyBankService类如下:
通过上面共享Connection对象的方法虽然可以完成事务处理的目的,但是这样做法是丑陋的,原因在于:为了完成事务处理的目的,我们需要将一个底层的Connection类在service层和DAO层之间进行传递,而DAO层的方法也要接受这个Connection对象,这种做法显然是不好的,这就是典型的API污染。
在下一篇博文中,我们将讲到如何在不传递Connection对象的情况下完成和本文相同的事务处理功能。
0 0
- Java事务处理全解析(三)——丑陋的案例
- Java事务处理全解析(三)—— 丑陋的案例
- Java事务处理全解析(三)—— 丑陋的案例
- Java事务处理全解析(三)—— 丑陋的案例
- Java事务处理全解析(三)—— 丑陋的案例
- java事务全解析(三)--丑陋的案例
- Java事务之三——丑陋的案例
- Java事务处理全解析(二)——失败的案例
- Java事务处理全解析(二)—— 失败的案例
- Java事务处理全解析(二)—— 失败的案例
- Java事务处理全解析(二)—— 失败的案例
- Java事务处理全解析(二)—— 失败的案例
- Java事务(3)——丑陋的案例
- Java事务处理全解析(四)—— 成功的案例(自己实现一个线程安全的TransactionManager)
- Java事务处理全解析(四)—— 成功的案例(自己实现一个线程安全的TransactionManager)
- Java事务处理全解析(四)—— 成功的案例(自己实现一个线程安全的
- Java事务处理全解析(四)—— 成功的案例(自己实现一个线程安全的TransactionManager)
- Java事务处理全解析(四)—— 成功的案例(自己实现一个线程安全的TransactionManager)
- Longhorn全解析及快速入门指南
- Spark集群硬件配置
- java -- 重载与覆盖
- 第5天:Pandas,露两手
- Python回炉学习<2>
- Java事务处理全解析(三)—— 丑陋的案例
- 第6天:数据合并
- Flume中的拦截器(Interceptor)介绍与使用(二)
- 【模板】KMP
- pycharm使用github
- A* Pathfinding Project (Unity A*寻路插件) 使用教程
- Java 判断文件夹、文件是否存在、否则创建文件夹
- 第7天:数据清洗(1)
- 17.5.2 经典相关分析(Canonical Correlation Analysis, CCA)