Java中数据库事务处理的实现.doc_第1页
Java中数据库事务处理的实现.doc_第2页
Java中数据库事务处理的实现.doc_第3页
Java中数据库事务处理的实现.doc_第4页
Java中数据库事务处理的实现.doc_第5页
已阅读5页,还剩9页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

Java中数据库事务处理的实现摘要 本文介绍在Java中进行事务处理的方法,通过实例分别讲述了如何采用JavaBean、Ejb组件实现J2EE应用服务器支持的JDBC事务、JTA(Java Transaction API)事务。关键词 JavaBean,EJB, 数据库,事务处理,JTAJavaBeanJavaBean是用Java语言编写的与平台无关的组件。它是描述Java的软件组件模型,有点类似于Microsoft的COM组件的概念。在Java模型中,通过JavaBean可以无限扩充Java程序的功能,通过JavaBean的组合可以快速的生成新的应用程序。JavaBean可以实现代码的重复利用,对于程序的易维护性也有重大的意义。非可视化的JavaBean,在JSP程序中常用来封装事务逻辑、数据库操作等,可以很好的实现业务逻辑和前台程序的分离。JavaBean在服务器端的应用方面表现出了越来越强的生命力。EJBEJB技术定义了一组可重用的组件:Enterprise JavaBeans。你可以利用这些组件,像搭积木一样的建立你的分布式应用程序。当你把代码写好之后,这些组件就被组合到特定的文件中去。每个文件有一个或多个Enterprise Beans,在加上一些配置参数。最后,这些Enterprise Beans被配置到一个装了EJB容器的平台上。客户能够通过这些Beans的home接口,定位到某个beans,并产生这个beans的一个实例。这样,客户就能够调用Beans的应用方法和远程接口。EJB技术简化了用JAVA语言编写的企业应用系统的开发、配置和执行。有三种类型的Enterprise beans: Session beans、 entity beans和Message-driven Beans。事务处理信息是任何企事业单位的重要资产,任何企业部门都包含着信息的流入、流出,任何企业部门都控制着某些信息。同时,信息必须在适当的时机传播给需要的人。而且,信息还需要安全约束,通常根据信息的类型和内容实施访问控制。为了保证数据的安全有效和正确可靠,数据库管理系统(DBMS)必须提供统一的数据保护功能。事务是现代数据库理论中的核心概念之一。如果一组处理步骤或者全部发生或者一步也不执行,我们称该组处理步骤为一个事务。当所有的步骤像一个操作一样被完整地执行,我们称该事务被提交。由于其中的一部分或多步执行失败,导致没有步骤被提交,则事务必须回滚(回到最初的系统状态)。事务必须服从ISO/IEC所制定的ACID原则。ACID是原子性(atomicity)、一致性(consistency)、隔离性(isolation)和持久性(durability)的缩写。事务的原子性表示事务执行过程中的任何失败都将导致事务所做的任何修改失效。一致性表示当事务执行失败时,所有被该事务影响的数据都应该恢复到事务执行前的状态。隔离性表示在事务执行过程中对数据的修改,在事务提交之前对其他事务不可见。持久性表示已提交的数据在事务执行失败时,数据的状态都应该正确。在下面我们列举一个使用SQL Server数据库进行事务处理的例子。主表是一个规章制度信息表(bylaw),主要字段有记录编号、标题、作者、书写日期等。两个子表分别是附件表(bylaw_affix)和文本信息表(bylaw_content)。表结构见图1所示。bylaw表的记录编号与bylaw_affix表的记录编号、bylaw_content表的记录编号是对应的,每次对规章制度信息的操作也就是对这三个表的联合操作。例如要删除规章制度中的一条记录,如果不使用事务,就可能会出现这样的情况:第一个表中成功删除后,数据库突然出现意外状况,而第二、三个表中的操作没有完成,这样,删除操作并没有完成,甚至已经破坏数据库中的数据。要避免这种情况,就应该使用事务,它的作用是:要么三个表都操作成功,要么都失败。换句话说,就是保持数据的一致性。所以,为了确保对数据操作的完整和一致,在程序设计时要充分考虑到事务处理方面的问题。图1 示例表结构Java中的事务处理一般情况下,J2EE应用服务器支持JDBC事务、JTA(Java Transaction API)事务、容器管理事务。一般情况下,最好不要在程序中同时使用上述三种事务类型,比如在JTA事务中嵌套JDBC事务。第二方面,事务要在尽可能短的时间内完成,不要在不同方法中实现事务的使用。下面我们列举两种事务处理方式。1、JavaBean中使用JDBC方式进行事务处理在JDBC中怎样将多个SQL语句组合成一个事务呢?在JDBC中,打开一个连接对象Connection时,缺省是auto-commit模式,每个SQL语句都被当作一个事务,即每次执行一个语句,都会自动的得到事务确认。为了能将多个SQL语句组合成一个事务,要将auto-commit模式屏蔽掉。在auto-commit模式屏蔽掉之后,如果不调用commit()方法,SQL语句不会得到事务确认。在最近一次commit()方法调用之后的所有SQL会在方法commit()调用时得到确认。 public int delete(int sID) dbc = new DataBaseConnection();Connection con = dbc.getConnection();try con.setAutoCommit(false);/ 更改JDBC事务的默认提交方式dbc.executeUpdate(delete from bylaw where ID= + sID);dbc.executeUpdate(delete from bylaw _content where ID= + sID);dbc.executeUpdate(delete from bylaw _affix where bylawid= + sID);mit();/提交JDBC事务con.setAutoCommit(true);/ 恢复JDBC事务的默认提交方式dbc.close();return 1;catch (Exception exc) con.rollBack();/回滚JDBC事务exc.printStackTrace();dbc.close();return -1;2、SessionBean中的JTA事务JTA 是事务服务的 J2EE 解决方案。本质上,它是描述事务接口(比如 UserTransaction 接口,开发人员直接使用该接口或者通过 J2EE 容器使用该接口来确保业务逻辑能够可靠地运行)的 J2EE 模型的一部分。JTA 具有的三个主要的接口分别是 UserTransaction 接口、TransactionManager 接口和 Transaction 接口。这些接口共享公共的事务操作,例如 commit() 和 rollback(), 但是也包含特殊的事务操作,例如 suspend(),resume() 和 enlist(),它们只出现在特定的接口上,以便在实现中允许一定程度的访问控制。例如,UserTransaction 能够执行事务划分和基本的事务操作,而 TransactionManager 能够执行上下文管理。应用程序可以调用UserTransaction.begin()方法开始一个事务,该事务与应用程序正在其中运行的当前线程相关联。底层的事务管理器实际处理线程与事务之间的关联。UserTmit()方法终止与当前线程关联的事务。UserTransaction.rollback()方法将放弃与当前线程关联的当前事务。public int delete(int sID) DataBaseConnection dbc = null;dbc = new DataBaseConnection();dbc.getConnection();UserTransaction transaction = sessionContext.getUserTransaction();/获得JTA事务try transaction.begin(); /开始JTA事务dbc.executeUpdate(delete from bylaw where ID= + sID);dbc.executeUpdate(delete from bylaw _content where ID= + sID);dbc.executeUpdate(delete from bylaw _affix where bylawid= + sID);mit(); /提交JTA事务dbc.close();return 1;catch (Exception exc) try transaction.rollback();/JTA事务回滚catch (Exception ex) /JTA事务回滚出错处理ex.printStackTrace();exc.printStackTrace();dbc.close();return -1; Last Modified: 2004.04.04 JBoss的集群策略分析(来源:) 序言在阅读本文前,请确定您有以下基础,否则您可能会是在浪费您的时间: 1、 了解J2EE的一些基本概念2、 了解集群的基本概念 3、 对JBOSS有一些大致的了解,可到上下载它。 JBOSS是一个开放源码的、基于J2EE规范的应用服务器,它实现了大多数的J2EE规范,除此之外,它还提供了一些J2EE中所没有涉及到的企业级功能,例如集群。本文主要描述JBOSS采取的集群策略,并重点介绍它的负载平衡与失效转发机制。由于JBOSS是一个建立在J2EE规范上的应用服务器,因此在开始之前,我们还是简单地介绍一下J2EE规范:J2EE是一套针对于企业级分布式应用的计算环境,它定义了动态WEB页面功能(servlet和jsp),商业组件(EJB),异步消息传输机制(JMS),名称和目录定位服务(JNDI),数据库访问(JDBC),与子系统的连接器(JCA),安全服务等等。但美中不足的是J2EE并没有定义一些企业级应用所必须的规范,例如集群,所以集群的实现只能由各厂商自行来设计实现。要实现基于J2EE规范的集群,我们通常要做如下考虑:集群的管理、负载平衡、失效转发、服务端状态的复制(例如JSP中的session),还要考虑同步和异步的问题(例如JMS服务就是异步方式)。如果要对这些内容做一个全面的阐述的话,估计可以写成一本书了:)因此本文主要探讨的是:怎样实现无状态EJB的负载平衡与失效转发机制?1999年,Marc Fleury建立了JBOSS开源项目,现在它有差不多100个活跃的开发者,30个核心开发者,每月高达35万次的下载量,它当前的最高稳定版是3.2版,4.0版正在稳定之中,自从JBOSS3.0开始就加入了集群技术,几乎能对任何J2EE规范进行集群管理,如JNDI、JSP中的session、EJB等等。更令人振奋的是,即将发行的JBOSS4.0将会对JMS也加入集群管理特色。 EJB集群在JBOSS中的实现下面言归正传,上图大致描述了一个客户端调用JBOSS中的EJB的过程。在JBOSS中,客户端并不直接调用EJB对像,而采用了一个迂回的方法,更专业的说是一种设计模式代理模式,真正与客户端交互的是一个代理对像,这个代理对像一般由客户端通过JNDI技术来取得的。而具体的代理对像的实现就由各厂商自完成了,在JBOSS中,一个代理对像是一段精心设计的复杂代码。但在客户端看来,调用一个代理对像好像就是在调用那个实际的EJB对像,虽然事实并非如此。在这里JBOSS耍了一个小把戏,代理对像虽然实现了与EJB对像相同的接口,但它实际上是把客户端对它的调用转发到了它在服务端的另一个伙伴身上,同时,这个伙伴同样定义了客户端所要求的一些EJB接口,当这些接口被调用时,精彩的部分开始了,JBOSS把客户端发过来的各种各样不同的调用全部转换成为一个统一格式的接口(在本文中我们暂且称客户端发出的调用为应用级接口,而JBOSS生成的统一格式的接口称为系统级接口)。当转换完成后,所有的应用级接口变成了系统级接口。为了能更清楚地阐述这个问题,我们假设客户端向EJB对像发出如下调用:myRemoteComponent.increaseSalary(100);/myRemoteComponent为代理对像这个调用实际上被JBOSS转换成了如下的系统级调用:proxyClientContainer.invoke(invocation); /proxyClientContainer为代理对像在服务端的另一个伙伴但这个invocation到底是什么呢?实际上它是类Invocation的一个实例,这里有它的一个简单的说明:public class InvocationObject args; /应用级接口中的一些参数Method method; /被调用的应用级接口Map payload; /JBOSS就是在这里采取的负载平衡策略的当应用级接口被转换成为了系统级接口之后,它将经过一系列的拦截器(至)。在这里我首先要说明一下什么是拦截器,实际上,它是JBOSS中独具特色的一个设计思路,一个拦截器就好像是一张过滤网,它用来对客户端的调用进行拦截,并对其进行一些处理,比如检查客户端调用的合法性、实现安全策略、对事务进行支持等。值得一提的是,JBOSS的集群管理也是通过拦截器来实现的,更令人欣慰的是,JBOSS的设计者并没有将这个拦截器固化在其核心内,而是采用一种插件式(plug-in)的方法来设计,因此你只要实现它的插件接口,你甚至可以写出自己的拦截器来,当然,这已不属于本文的讨论范围之内了。这里(至)的每个拦载器将顺序地拦截invocation,它们都具有如下的集群管理方面的能力:1、 分析invocation的内容和任务。2、 加入一些信息到invocation中的payload中,以优化集群策略。3、 读取出放在payload中的任何可用信息。4、 将invocation转发到下一个拦截器中。5、 如果发生错误,能够将错误报告给调用者,并返回到正确的地方去。值得注意的是最后一个拦截器,它有一些特殊,因为它才真正地执行对实际的EJB的调用,它能检测到客户端是否和EJB对像在同一个Java虚拟机中,如果是的话,它只是简单地将这个调用直接传给EJB对像,这样做的原因是可以避免由于网络传输带来的不必要的开销,使用调用速度大大加快。另一方面,如果客户端与EJB不在同一个虚拟机中,那么它们就要通过网络传输了,在这里JBOSS提供了另一个有趣的策略,就是代理对像并不知道采取的是什么传输协议,只有最后那个拦截器才知道真正采用的传输协议是什么。就目前而言,它提供了RMI/JRMP、IIOP、HTTP、SOAP等协议来进行传输。当我们设计JBOSS的集群策略时,我们还必须决定究竟要在哪儿将负载平衡以及失效转发行激活,为此,请先看下图:1、 在某个服务器结点上发生2、 在一个中介服务器上进行发生3、 在客户端上进行发生上图中的3种方案都有其利弊,但我们觉得最后一个方法要比前2个好,原因如下:1、 与第2种方案相比,它避免了由于中介服务器失效而引发的全线崩溃。2、 除非客户端崩溃,负载平衡和失效转发策略才会失败。而我想应该没有人会对此产生报怨的。这也没有什么好报怨的,不是吗?3、 从性能方面来考虑,这种方案也是最优的,因为所有的策略都是发生在客户端的,省去了第1、2种方案由服务器来管理带来的瓶颈。因此,我们选择了最后一种方案来做为JBOSS的集群策略。其实,只要大家再仔细回顾一下前面的部分,就会发现我们先前描述的方案不正是第3种方案吗?但我们现在必须对这个策略在以下几个方面做一些更深入的分析:1、 我们必须加入真正实现负载平衡的逻辑。2、 当客户端发出调用时,我们应该能够决定到底将它发送到哪个服务器节点上。3、 我们希望为客户端代理对像设计一个比较合适的服务器结点的拓扑图,以便我们做出好的集群策略。负载平衡的设计策略前面已经说过,JBOSS的负载平衡与失效转发策略是由最后一个拦截器实现的(上图中的),然而我们要考虑的是虽然客户端只发出一个调用,但针对于代理对像的调用可能包含多个可用的服务器结点,其个数等于集群中所有有效节点之和(参见上图中的),那么到底是由谁来决定这个策略的呢?这个工作由一个叫插件式的负载平衡策略来实施的(在下一段中简称策略,如下图)。当客户端调用到达最后一个拦截器的时候,拦截器会请求策略来为它选择一个服务器结点。如果此结点有效且调用成功,则结果会返回给代理对像,如果失败了,拦截器不会直接将错误返回给代理对像,而是将这个错误信息报告给策略,并请求它再为客户端选择一个新节点。但还有一个问题值得考虑的,就是对一些致命性错误的处理。例如某个数据库服务器突然崩溃了,那么最后一个拦截器将无法对此进行失效转发了,因为不管选择哪个服务器结点都不能解决这个问题了,在这里拦截器会将错误报告给客户端,并由其自已做出决定。IT界里好像有这样一个原理,就是越是可扩展性强,灵活的东西实施起来就越复杂。在JBOSS中也不例外,但幸运的是这些工作并没为给客户端带来额外的编程负担,因为所有策略的配置都是在服务器完成的。JBOSS的集群配置遵循XML规范,下面是的一个普通EJB对像的典型集群配置:jbossenterprise-beanssessionejb-nameMySessionBean/ejb-nameclusteredTrue/clusteredcluster-configpartition-nameDefaultPartition/partition-namehome-load-balance-policy erfaces.RoundRobin/erfaces.FirstAvailable/bean-load-balance-policy/cluster-config/session/enterprise-beans/jboss上述配置说明了一个名为MySessionBean的会话Bean的集群策略,它定义了名为DefaultPartion的缺省策略名称,并定义了2个具体的策略。当然,如果你觉得它比较复杂,而只想用JBOSS缺省的集群策略的话,可以将整个cluster-config标签去掉。最后还有一个小问题值得考虑:由于集群策略是发生在客户端的,当客户端发出调用请求时,它不得不下载它的代理对像、拦截器、负载平衡策略等等。如果要下载的内容过多,会影响客户端的调用速度,这里JBOSS采取了一种延迟下载的方法,就是每次只下载一个必须的类,而不是一次全部下载,这样就能使性能得到较大的改善。服务器结点拓扑图的刷新JBOSS的集群实现是动态的,也就是说你可以动态地往集群中加入一个新节点或关闭任意一个节点,而不用费力地维护一张静态的拓扑图,就好像是JBOSS自己有能力管理集群一样。这个思想够先进吧?但与此同时它也带来了一些令人头痛的问题,请先看下图:由于JBOSS的集群策略是在客户端进行的,那么客户端在调用EJB的时候会将所有必须的组件下载下来,然后由其进行集群决策。如果我们设T为时间,且t0t1t2,那么当处于t0时刻时,集群拓扑图中包含server1和server2两个节点,客户端的调用被转发到了结点2上。当处于t1时刻时,server1和server2全部都崩溃了。当处于t2时刻时,管理员增加了server3和server4两个节点,但客户端的拓扑图中还只是包含原先的server1和server2两节点的信息,因为它无法知道这新加入的2个节点。为了解决这个问题,JBOSS是这

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论