如何理解嵌套事务(nested transaction) -凯发k8网页登录

 

如何理解嵌套事务(nested transaction)

目前,似乎很少有支持嵌套事务的中间件,但嵌套事务确实存在。
假定有method a, method b, method c
a 调用 b,c
servicehost {    
        
    
/**   
     * 事务属性配置为 propagation_required   
     
*/   
    
void invoke() {    
      try{
           servicea.invoke()
      } 
catch (bussiness.a.exception) { 
           abort()
      }

        
try {    
            serviceb.invoke();    
        } 
catch (bussiness.b.exception) {    
            servicec.invoke();
        } 
catch (bussiness.c.exception) {    
            serviced.invoke();
        } catch (bussiness.d.exception) { 
           abort()
      }

  
        
try{
           servicee.invoke()
        } 
catch (bussiness.e.exception) { 
           servicef.invoke()
        }catch (bussiness.f.exception) { 
           abort()
      }


    }    
   

servicea {    
        
    
/**   
     * 事务属性配置为 propagation_nested, 
     × 即该事务需要被嵌套   
     
*/     
    
void methoda() {    
    }    
        
}

servicea, serviceb, servicec, serviced, servicee, servicef都配置为propagation_nested
通过这样的嵌套规约,我们可以满足业务完整性的需求,一个serviceparent 业务,只允许出现a-b-e , a-b-f, a-c-e, a-c-f, a-d-ea-d-f的组合,其他组合,如a-b-c, a-e, b-f都是不允许的。

 

术语上,servicea, b, c, d, e, f的事务均是serviceparent事务的子事务,现在,是serviceparent嵌套servicea-f,且嵌套事务的几个特性如下:

1,  假定子事务(servicea-f)处于活动状态(active),则parent事务(serviceparent)不能执行任何其他操作,父事务只能commit事务,abort事务以及创建更多其它子事务。

2,  若子事务(servicea)被提交了,此时父事务则能够看到子事务做出的任何修改,这些修改,对其他子事务来说是隐藏的,直到父事务提交为止。

3,  同样地,如果被嵌套的事务servicea被回滚了,则它也不会对父事务有任何影响,且父事务servieparent也不会看到servicea曾经修改过的数据。

4,  最终父事务提交、回滚才会决定到子事务的提交、回滚。表达的形象点,若servicea“提交”后,serviceparent却因为service b/c/d都无法成功执行,servicea会回滚。这种做法依赖于jdbc 3.0 savepoint技术。

5,  嵌套子事务提交后,它对db的锁其实并没有释放,这些锁的控制权被转交给父事务,直到父事务提交(或回滚)后,锁才会真正释放

6,  目前,嵌套的深度不收控制,也就是,我们可对method进行以深度嵌套。

 

 

           

      现在,我们略略了解一下jdbc savepoint技术,它给予了我们这样的能力,在一个事务里面,我们能够将已经提交的事务状态,恢复到一个事务commit以前的任意定点(这个点就是savepoint)

            举个例子,假设我们面临这样一种情况,methoda是运算代价非常大的事务操作,methodb, methodc都是轻量级的事务,我们需要执行这样一个事务tx={methoda->methodb->methodc}

           没有savepoint之前,如果methoda执行成功,但是恰恰methodb失败了,那么methoda所有成果必须回滚,methodc也别想执行了,因为methodamethodbmethodc都在同一个tx事务中;jdbc3.0savepoint技术为我们提供了一个无需回滚methoda的折衷办法,可以让我们在保留methoda的成果的同时,仅仅回滚methodb,然后继续执行methodc

      回滚到savepoint的代码类似于:

statement stmt = conn.createstatement();
int rows = stmt.executeupdate("insert into tab1 (col1) values " 
"(’first’)");
// set savepoint
savepoint svpt1 = conn.setsavepoint("savepoint_1");
rows 
= stmt.executeupdate("insert into tab1 (col1) " 
"values (’second’)");

conn.rollback(svpt1);

conn.commit();

posted on 2008-03-04 12:38 david.turing 阅读(9974) 评论(4)  编辑  收藏 所属分类: java日积月累

# re: 如何理解嵌套事务(nested transaction) 2008-03-17 23:32

个人对事务的理解比较片面:要么一起成功,要么一起失败,所接触的用户需求基本也都是这样的,没有出现要求部分成功/部分失败的情况.
了解savepoint的概念,但是不知道hibernate里面是否支持这个操作...,有空试试.嘿嘿.  回复     

# re: 如何理解嵌套事务(nested transaction) 2008-04-05 11:12

麻烦大大给个confluence破解包的解压密码
toughwhite@gmail.com 谢谢!!!!  回复     

# re: 如何理解嵌套事务(nested transaction) 2008-04-30 15:04

数据库本质上从来没有过嵌套事务的概念,只是应用程序为了不同的目的将对事务的操作过程嵌套起来,即使是oracle的自治事务也可划为应用程序(存储过程或是触发器什么的),, 从应用角度讲,嵌套事务处理就是应用程序如何将应用层面的嵌套转变为数据库层面的单事务操作, 这方面java领域的ejb,spring提供了方面的凯发天生赢家一触即发官网的解决方案,另外提一下jta,它提供了事务的suspend,resume功能,实质上其实数据库事务那里有什么挂起什么的概念,其仅仅是换了一个数据库连接,这样新的数据库事务开始了,老的数据库事务便不再操作,直接其被resume.  回复     

# re: 如何理解嵌套事务(nested transaction) 2008-04-30 15:12

当然save point确实提供了事务部分回退的操作,这是数据库层面提供的功能,jdbc3只是提供了支持而矣, 但是这本身还是线性的,没有什么嵌套的概念.

"要么一起成功,要么一起失败"这肯定没有问题 ,关键是事务结束只有两个可能, commit,rollback,故save point只是事务中间的一个小玩意,跟事务完整性无任何关系.  回复     

导航

统计

常用链接

留言簿(109)

我参与的团队

随笔分类(126)

随笔档案(155)

文章分类(9)

文章档案(19)

相册

搜索

积分与排名

最新随笔

最新评论

阅读排行榜

评论排行榜

网站地图