java

位置:IT落伍者 >> java >> 浏览文章

JAVA设计模式之事务处理[1]


发布日期:2024年08月27日
 
JAVA设计模式之事务处理[1]
事务处理是企业应用需要解决的最主要的问题之一JEE通过JTA提供了完整的事务管理能力包括多个事务性资源的管理能力但是大部分应用都是运行在单一的事务性资源之上(一个数据库)他们并不需要全局性的事务服务本地事务服务已然足够(比如JDBC事务管理)

本文并不讨论应该采用何种事务处理方式主要目的是讨论如何更为优雅地设计事务服务仅以JDBC事务处理为例涉及到的DAOFactoryProxyDecorator等模式概念请阅读相关资料

也许你听说过事务处理应该做在service层也许你也正这样做但是否知道为什么这样做?为什么不放在DAO层做事务处理显而易见的原因是业务层接口的每一个方法有时候都是一个业务用例(User Case)它需要调用不同的DAO对象来完成一个业务方法比如简单地以网上书店购书最后的确定定单为例业务方法首先是调用BookDAO对象(一般是通过DAO工厂产生)BookDAO判断是否还有库存余量取得该书的价格信息等然后调用CustomerDAO从帐户扣除相应的费用以及记录信息然后是其他服务(通知管理员等)简化业务流程大概如此:

注意我们的例子忽略了连接的处理只要保证同一个线程内取的是相同的连接即可(可用ThreadLocal实现)

首先是业务接口针对接口而不是针对类编程

public interface BookStoreManager{

public boolean buyBook(String bookIdint quantity)throws SystemException;

其他业务方法

}

接下来就是业务接口的实现类??业务对象

public class BookStoreManagerImpl implements BookStoreManager{

public boolean buyBook(String bookId)throws SystemException{

Connection conn=ConnectionManagergetConnection();//获取数据库连接

boolean b=false;

try{

connsetAutoCommit(false); //取消自动提交

BookDAO bookDAO=DAOFactorygetBookDAO();

CustomerDAO customerDAO=DAOFactorygetCustomerDAO();

//尝试从库存中取书

if(BookDAOreduceInventory(connbookIdquantity)){

BigDecimal price=BookDAOgetPrice(bookId); //取价格

//从客户帐户中扣除price*quantity的费用

b=

CustomerDAOreduceAccount(connpricemultiply(new BigDecimal(quantity));

其他业务方法如通知管理员生成定单等

conncommit(); //提交事务

connsetAutoCommit(true);

}

}catch(SQLException e){

connrollback(); //出现异常回滚事务

consetAutoCommit(true);

eprintStackTrace();

throws new SystemException(e);

}

return b;

}

}

然后是业务代表工厂

public final class ManagerFactory {

public static BookStoreManager getBookStoreManager() {

return new BookStoreManagerImpl();

}

}

这样的设计非常适合于DAO中的简单活动我们项目中的一个小系统也是采用这样的设计方案但是它不适合于更大规模的应用首先你有没有闻到代码重复的 bad smell?每次都要设置AutoCommit为false然后提交出现异常回滚包装异常抛到上层写多了不烦才怪那能不能消除呢?其次业务代表对象现在知道它内部事务管理的所有的细节这与我们设计业务代表对象的初衷不符对于业务代表对象来说了解一个与事务有关的业务约束是相当恰当的但是让它负责来实现它们就不太恰当了再次你是否想过嵌套业务对象的场景?业务代表对象之间的互相调用层层嵌套此时你又如何处理呢?你要知道按我们现在的方式每个业务方法都处于各自独立的事务上下文当中(Transaction Context)互相调用形成了嵌套事务此时你又该如何处理?也许办法就是重新写一遍把不同的业务方法集中成一个巨无霸包装在一个事务上下文中

我们有更为优雅的设计来解决这类问题如果我们把Transaction Context的控制交给一个被业务代表对象DAO和其他Component所共知的外部对象当业务代表对象的某个方法需要事务管理时它提示此外部对象它希望开始一个事务外部对象获取一个连接并且开始数据库事务也就是将事务控制从service层抽离当web层调用service层的某个业务代表对象时返回的是一个经过Transaction Context外部对象包装(或者说代理)的业务对象此代理对象将请求发送给原始业务代表对象但是对其中的业务方法进行事务控制那么我们如何实现此效果呢?答案是JDK引进的动态代理技术动态代理技术只能代理接口这也是为什么我们需要业务接口BookStoreManager的原因

首先我们引入这个Transaction Context外部对象它的代码其实很简单如果不了解动态代理技术的请先阅读其他资料

[] []

               

上一篇:Java性能优化

下一篇:JAVA设计模式之事务处理[2]