java事务处理

Posted

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了java事务处理相关的知识,希望对你有一定的参考价值。

麻烦请详细描述java中的事务处理,如果有多种请列出。

如果对数据库进行多次操作,每一次的执行或步骤都是一个事务.如果数据库操作在某一步没有执行或出现异常而导致事务失败,这样有的事务被执行有的就没有被执行,从而就有了事务的回滚,取消先前的操作.....
JavaBean中使用JDBC方式进行事务处理

public int delete(int sID)
  dbc = new DataBaseConnection();
  Connection con = dbc.getConnection();
  try
   con.setAutoCommit(false);// 更改JDBC事务的默认提交方式
   dbc.executeUpdate("delete from xiao where ID=" + sID);
   dbc.executeUpdate("delete from xiao_content where ID=" + sID);
   dbc.executeUpdate("delete from xiao_affix where bylawid=" + sID);
   con.commit();//提交JDBC事务
   con.setAutoCommit(true);// 恢复JDBC事务的默认提交方式
   dbc.close();
   return 1;
 
  catch (Exception exc)
   con.rollBack();//回滚JDBC事务
   exc.printStackTrace();
   dbc.close();
   return -1;
 


在数据库操作中,一项事务是指由一条或多条对数据库更新的sql语句所组成的一个不可分割的工作单元。只有当事务中的所有操作都正常完成了,整个事务才能被提交到数据库,如果有一项操作没有完成,就必须撤消整个事务。

例如在银行的转帐事务中,假定张三从自己的帐号上把1000元转到李四的帐号上,相关的sql语句如下:

update account set monery=monery-1000 where name='zhangsan'

update account set monery=monery+1000 where name='lisi'

这个两条语句必须作为一个完成的事务来处理。只有当两条都成功执行了,才能提交这个事务。如果有一句失败,整个事务必须撤消。

在connection类中提供了3个控制事务的方法:

(1) setAutoCommit(Boolean autoCommit):设置是否自动提交事务;

(2) commit();提交事务;

(3) rollback();撤消事务;

在jdbc api中,默认的情况为自动提交事务,也就是说,每一条对数据库的更新的sql语句代表一项事务,操作成功后,系统自动调用commit()来提交,否则将调用rollback()来撤消事务。

在jdbc api中,可以通过调用setAutoCommit(false) 来禁止自动提交事务。然后就可以把多条更新数据库的sql语句做为一个事务,在所有操作完成之后,调用commit()来进行整体提交。倘若其中一项sql操作失败,就不会执行commit()方法,而是产生相应的sqlexception,此时就可以捕获异常代码块中调用rollback()方法撤消事务。
参考技术A 学习Java 建议你一定要学学ssh框架 即:struts+spring+hibernate在j2ee开发中 它是很重要的开源框架使用ssh后 通过spring来管理应用程序中的事务会显得格外简单 参考技术B 等你有了答案告诉我啊

JAVA XA分布式事务处理


       在谈到 XA 规范之前,必须首先了解分布式事务处理( Distributed Transaction Processing , DTP )的概念。 Transaction ,即事务,又称之为交易,指一个程序或程序段,在一个或多个资源如 数据库 或文件上为完成某些功能的执行过程的集合。

  分布式事务处理是指一个事务可能涉及多个数据库操作,分布式事务处理的关键是必须有一种方法可以知道事务在任何地方所做的所有动作,提交或回滚事务的决定必须产生统一的结果(全部提交或全部回滚)。   X/Open 组织(即现在的 Open Group )定义了分布式事务处理模型。 X/Open DTP 模型( 1994 )包括应用程序( AP )、事务管理器( TM )、资源管理器( RM )、通信资源管理器( CRM )四部分。一般,常见的事务管理器( TM )是交易中间件,常见的资源管理器( RM )是数据库,常见的通信资源管理器( CRM )是消息中间件。  通常把一个数据库内部的事务处理,如对多个表的操作,作为本地事务看待。数据库的事务处理对象是本地事务,而分布式事务处理的对象是全局事务。 所谓全局事务,是指分布式事务处理环境中,多个数据库可能需要共同完成一个工作,这个工作即是一个全局事务,例如,一个事务中可能更新几个不同的数据库。对数据库的操作发生在系统的各处但必须全部被提交或回滚。此时一个数据库对自己内部所做操作的提交不仅依赖本身操作是否成功,还要依赖与全局事务相关的其它数据库的操作是否成功,如果任一数据库的任一操作失败,则参与此事务的所有数据库所做的所有操作都必须回滚。


一般情况下,某一数据库无法知道其它数据库在做什么,因此,在一个 DTP 环境中,交易中间件是必需的,由它通知和协调相关数据库的提交或回滚。而一个数据库只将其自己所做的操作(可恢复)影射到全局事务中。   
XA 就是 X/Open DTP 定义的交易中间件与数据库之间的接口规范(即接口函数),交易中间件用它来通知数据库事务的开始、结束以及提交、回滚等。 XA 接口函数由数据库厂商提供。

XA 与两阶段提交协议   通常情况下,交易中间件与数据库通过 XA 接口规范,使用两阶段提交来完成一个全局事务, XA 规范的基础是两阶段提交协议。  在第一阶段,交易中间件请求所有相关数据库准备提交(预提交)各自的事务分支,以确认是否所有相关数据库都可以提交各自的事务分支。当某一数据库收到预提交后,如果可以提交属于自己的事务分支,则将自己在该事务分支中所做的操作固定记录下来,并给交易中间件一个同意提交的应答,此时数据库将不能再在该事务分支中加入任何操作,但此时数据库并没有真正提交该事务,数据库对共享资源的操作还未释放(处于上锁状态)。如果由于某种原因数据库无法提交属于自己的事务分支,它将回滚自己的所有操作,释放对共享资源上的锁,并返回给交易中间件失败应答。 在第二阶段,交易中间件审查所有数据库返回的预提交结果,如所有数据库都可以提交,交易中间件将要求所有数据库做正式提交,这样该全局事务被提交。而如果有任一数据库预提交返回失败,交易中间件将要求所有其它数据库回滚其操作,这样该全局事务被回滚。   
以一个全局事务为例, AP 首先通知交易中间件开始一个全局事务,交易中间件通过 XA 接口函数通知数据库开始事务,然后 AP 可以对数据库管理的资源进行操作,数据库系统记录事务对本地资源的所有操作。操作完成后交易中间件通过 XA 接口函数通知数据库操作完成。交易中间件负责记录 AP 操作过哪些数据库(事务分支)。 AP 根据情况通知交易中间件提交该全局事务,交易中间件会通过 XA 接口函数要求各个数据库做预提交,所有数据库返回成功后要求各个数据库做正式提交,此时一笔全局事务结束。   
XA 规范对应用来说,最大好处在于事务的完整性由交易中间件和数据库通过 XA 接口控制, AP 只需要关注与数据库的应用逻辑的处理,而无需过多关心事务的完整性,应用设计开发会简化很多。  

 
具体来说,如果没有交易中间件,应用系统需要在程序内部直接通知数据库开始、结束和提交事务,当出现异常情况时必须由专门的程序对数据库进行反向操作才能完成回滚。如果是有很多事务分支的全局事务,回滚时情况将变得异常复杂。而使用 XA 接口,则全局事务的提交是由交易中间件控制,应用程序只需通知交易中间件提交或回滚事务,就可以控制整个事务(可能涉及多个异地的数据库)的全部提交或回滚,应用程序完全不用考虑冲正逻辑。   
在一个涉及多个数据库的全局事务中,为保证全局事务的完整性,由交易中间件控制数据库做两阶段提交是必要的。但典型的两阶段提交,对数据库来说事务从开始到结束(提交或回滚)时间相对较长,在事务处理期间数据库使用的资源(如逻辑日志、各种锁),直到事务结束时才会释放。因此,使用典型的两阶段提交相对来说会占用更多的资源,在网络条件不是很好,如低速网、网络颠簸频繁,情况会更为严重。   
当一个全局事务只涉及一个数据库时,有一种优化方式,即一阶段提交。当 AP 通知交易中间件提交事务时,交易中间件直接要求数据库提交事务,省去两阶段提交中的第一阶段,可以缩短处理一个事务的时间,以提高事务处理的效率。作为两阶段提交的一种特例,与两阶段一样,一阶段提交也是标准的。


如何关注China中间件?

  • 回文章顶部,点击蓝色字体“China中间件”进行订阅


以上是关于java事务处理的主要内容,如果未能解决你的问题,请参考以下文章

关于django出现重复点击,多事务处理

Mybatis事务处理

Java实现通用线程池

面试官:小伙子你给我说说MySq|并发事务处理细节

NetCore微服务实现事务一致性masstransit之saga使用

微服务实施中分布式事务的解决方案