iBATIS事务处理浅析

iBATIS事务处理这部分是和Dao紧密相联的。

我们在使用Dao时，如以下代码，先插入新记录，再进行更新：

 
 
personDao.insertPerson (person); // Starts transaction  
person.setLastName("Begin");  
personDao.updatePerson (person); // Starts a new transaction 

因为没有显式地启动事务，iBatis会认为这是两次事务，分别从连接池中取两次Connectio。

我们所写的Dao子类（继承自com.ibatis.dao.client.template.SqlMapDaoTemplate）的每一个Dao方法已经默认为一个事务（通过动态代理）。

而在业务层，应该有一个类来统管Dao子类的事务，iBatis是通过DaoManager类来作这件事的，如下：

DaoManager provides access to all DAOs it manages and also allows transactions to be committed and ended (possibly rolled back)

众Dao子类由DaoManager产生,如：

 
 
DaoManager daoManager = DaoManagerBuilder.buildDaoManager(reader);  
 
UserDao userDao = (UserDao) daoManager.getDao(UserDao.class); 

UserDao是用户自己定义的接口，获得的其实是在dao.xml中指定的相对应的 SqlMapDao实现类，从而实现了松藕合。在良好的分层设计中，

iBATIS事务处理之业务层（service包）只需要知道Dao接口，而不去关心其具体怎么实现。

如果显式地声明事务处理语句，如下：

 
 
try {  
daoManager.startTransaction();  
personDao.insertPerson (person);   
person.setLastName("Begin");  
personDao.updatePerson(person);   
otherDao.doSomething(other);  
...  
daoManager.commitTransaction();  
} finally {  
daoManager.endTransaction();  
} 

这样就保持了原子性，整体为一个事务，要么全部执行成功，否则回滚。

现在唯一的问题就是，dao层的事务是否已经放弃，否则产生事务嵌套问题对性能会有影响

当然，iBatis 完全可以这么做：建一个声明式接口:IService,再使用动态代理，将用户自己的Serivce子类通过动态代理自动包上事务处理的代码，默 认每一个业务方法为一个事务。

大师的心如果能轻易揣测，就是不大师了:),估计大师认为这样属于过度设计，他认为把这种灵活性交给用户是合适的，相当多的service 方法只调用一个Dao方法，例如CRUD操作。

再补充一下，iBatis中对事务的处理是可配置的，最常用的Type是"JDBC",也可以声明为"JTA"或"EXTERNAL".