BlogJava-重归混沌-随笔分类-设计思想

什么是JTA

王永庆 — Fri, 16 Oct 2009 06:23:00 GMT

Java Transaction API（Java事务API） (JTA)Java Transaction API(Application Programming Interface)

什么是JTA Transaction？它有怎样的特点呢？JTA Transaction是指由J2EE Transaction manager去管理的事务。其最大的

特点是调用UserTransaction接口的begin，commit和rollback方法来完成事务范围的界定，事务的提交和回滚。JTA

Transaction可以实现同一事务对应不同的数据库，但是它仍然无法实现事务的嵌套。

分布式事务的规范由OMG的OTS所描述。
JTA是只是一组java接口用于描述，J2ee框架中事务管理器与应用程序，资源管理器，以及应用服务器之间的事务通讯。
它主要包括高层接口即面向应用程序的接口；XAResource接口即面向资源的接口；以及事务管理器的接口。值得注意的是JTA

只提供了接口，没有具体的实现。
JTS是服务OTS的JTA的实现。简单的说JTS实现了JTA接口，并且符合OTS的规范。

资源管理器只要其提供给事务管理器的接口符合XA接口规范，就可以被事务管理器处理。

所以，JTA可以处理任何提供符合XA接口的资源。包括：数据库，JMS，商业对象等等

“Java 事务 API”（JTA）启用两阶段提交功能。当配置 WebSphere Application Server 以访问数据库时，可选择具有

JTA 能力的驱动程序。如果需要两阶段提交功能，则必须使用启用 JTA 的驱动程序。
只要您在事务中调用了多个数据库连接，就需要 JTA。只要您在事务中调用了多个数据库服务器，就需要两阶段提交。这些

连接可以是相同的物理数据库服务器或多个数据库服务器。例如：

    * 实体企业 Bean Entity1 在应用程序服务器 AppServer1 中部署。
    * 实体企业 Bean Entity2 在应用程序服务器 AppServer1 中部署。
    * 会话企业 Bean Session1 在应用程序服务器 AppServer1 中部署。

如果 Session1 对同一事务内的 Entity1 和 Entity2 调用了方法而这两个企业 Bean 正在使用不同的物理数据库连接，则

必须对 Entity1 和 Entity2 使用的数据源启用 JTA。当从相同的数据源对象获取那些连接时，这也是成立的。这需要具有

JTA 能力的驱动程序以提交事务。
当事务涉及到多个进程时，JTA 也是必需的。例如，一个事务可能会涉及在多个应用程序服务器中部署的企业 Bean。

    * 实体企业 Bean Entity1 在应用程序服务器 AppServer1 中部署。
    * 实体企业 Bean Entity2 在应用程序服务器 AppServer2 中部署。
    * 会话企业 Bean Session1 在应用程序服务器 AppServer1 中部署。

如果 Session1 对同一事务（此事务构成一个分布式事务）内的 Entity1 和 Entity2 调用了方法，则必须对 Entity1 和

Entity2 使用的数据源启用 JTA。
性能实现JTA 启用的连接与非 JTA 启用的连接执行情况不同。基于此原因，如果您的应用程序不需要 JTA，则最好使用非

JTA 启用的驱动程序。

王永庆 2009-10-16 14:23 发表评论

什么是J2EE集群

王永庆 — Mon, 05 Oct 2009 03:59:00 GMT

    现在有越来越多的关键应用和大型应用是基于J2EE 来创建的，像银行系统和帐单系统这些关键应用要求有很高的可用性，而Google 和Yahoo 这样的大型应用就需要很好的可扩展性。在如今这个联系越来越紧密的世界，高可用性和良好的可扩展性的重要性日益突出。例如在1999 年6 月份，eBay 的服务停止了22 个小时，导致大约230 万的拍卖被中断，eBay 的股票也随之下降
了9.2 个百分点。
       J2EE 集群就是一种能够提供高可用性、可扩展性以及容错性的流行技术。但是由于在J2EE 规范中没有对集群做出规范，各个J2EE 厂商就使用不同的方式来实现集群，这样就给系统架构师和开发人员带来了很多麻烦。下面就是常见的一些问题：
•     为什么带有集群支持的商业J2EE 服务器产品如此昂贵？（是无集群支持产品的10 倍）
•     为什么在单机环境下创建的应用在集群环境中无法正常运行？
•     为什么我的应用在集群环境下运行的非常慢，但是在单机模式下却没有这个问题？
•     为什么我的集群应用在向其他厂商的服务器迁移时会失败？
要理解为什么会有这些限制，最好的方法就是研究它的实现，以揭开J2EE 集群的面纱。

基本术语
       在我们开始讨论对于集群不同的实现之前，我想，了解一下集群技术的一些基本概念还是很有意义的。希望本章不单单是告诉你这些概念和设计问题，也同时能够为你勾勒一下不同J2EE集群实现的框架以便于理解。
可扩展性
       在一些大型系统中，很难提前预知最终用户的数量以及他们的使用行为，所以，可扩展性就是指一个系统能够快速适应用户数量的增加。提高服务器处理能力的最直接的方法就是增加硬件资源，例如CPU、内存或者硬盘等。集群是解决这个问题的另外一种方式，它使得一组服务器共同分担繁重的任务，但对于最终用户来说就像一台服务器。

高可用性
     通过向单机添加硬件来扩展系统能力的方案并不可靠，因为单一的服务器存在一个单点故障。像银行系统、帐单系统这样的关键应用甚至连一分钟的停机都不能容许，它们需要在任何时间都是可用的，并且要能够保证响应速度。集群技术就可以满足这个要求，它通过加入冗余服务器使得在一个服务器出错而停止服务的时候，这些冗余的服务器可以继续服务。

负载均衡
     负载均衡是集群的另外一个关键技术，它通过将请求分发到不同的服务器来达到高可用性和高效的处理能力。负载均衡器可以是一个servlet，也可以是一个插件（例如Linux 上的ipchains），甚至还可以是一个比较昂贵的内嵌了SSL 支持的硬件产品。为了能够分发请求，负载均衡器还需要做一些重要的工作，例如使用“会话粘滞”技术以确保来自同一个用户的请求会被转发到同一个服务器；使用“健康检查”（或者“心跳监听”）技术来防止将请求转发到一个失败的服务器；有时候负载均衡器还将参与“失败转移”的工作。

容错
       高可用的数据并不必是严格正确的数据。在J2EE 集群中，当一个服务器实例失败了，在集群中冗余的服务器就可以处理新到的请求，这样就保证了服务依然可用。但是在服务器失败的那一刻，正在被处理的请求就可能无法得到正确的数据。那么，带有容错功能的集群就可以确保请求所得到的数据是正确的，哪怕是服务器端出现了错误。
       这个是怎么实现的呢？确实需要我们去进行思考！

失败转移
       在集群中，失败转移是实现容错的一个关键技术。当最初的节点失败之后，在集群中选择另外一个节点来完成处理。失败转移到其他节点可以通过编码实现，也可以由平台自动实现。

幂等方法
       如果一个方法使用同样的参数进行多次调用所得到的结果都一样，也就是说对于该方法的调用次数不影响系统，那么这个方法就叫做“幂等方法”。例如 “getUsername()”就是一个幂等方法，而“deleteFile()”就不是幂等的。在讨论 HTTP 会话失败转移和EJB 的失败转移时，幂等方法是一个很重要的概念

王永庆 2009-10-05 11:59 发表评论

什么是重轻量

王永庆 — Mon, 05 Oct 2009 03:55:00 GMT

重/轻量：其实是使用难易程度，从根本上说，重/轻量应该和可伸缩性不矛盾的，特别是EJB 3.0推出以后，这个问题应该得到比较好的解决。
　　但是，在目前情况下，编写一个JavaBeans要比编写一个EJB容易多，那么，是重/轻量还是可伸缩性应该成为系统架构的主要依据呢？在这个问题背后，还隐藏了目前在开源领域两个架构技术选择：
　　1. 重量：基于JBoss/EJB的完整J2EE系统架构（具有可伸缩性，目前不易于学习）
　　2. 轻量：基于Tomcat的Struts+Hibernate/Spring+Hibernate （目前无太大可伸缩性，但是易于学习使用）

因为轻量解决方案易于学习新技术，容易使用，选中率比较高。但是让人产生对系统的可伸缩性担忧。鉴于这种情况，我认为有必要强调一下可伸缩性的重要性，切不能因为要跟进新的设计思想和技术，而盲目地采用一个无可伸缩性的设计方案。

其实，"轻量"应该是一个中性词，但是因为大量新的设计思想比较容易通过轻量方案获得成型软件，如（Spring/Naning/Hibernate）等，逐渐的"轻量"好像变成了一个褒义词。如果从可伸缩性的标准看，轻量还可能是一个贬义词，轻量意味着丧失重量系统中的分布式网络计算的设计考量，那么可伸缩性就要打问号。

从这次JavaOne大会以及从长远来看，随着EJB 3.0中间件轻量化、SOA架构理念普及，轻量/重量的区别已经模糊，如果还是以轻量/重量作为架构选择的标准，甚至标榜自己的系统，无疑是不明智的。

可伸缩性应该依然是实用企业系统架构的主选，可伸缩性是站在软件公司的客户企业立场，为这些客户企业考虑的，但是他们经常因为被认为是外行，挡在了软件系统架构选择的门外。

王永庆 2009-10-05 11:55 发表评论

什么是可伸缩性

王永庆 — Mon, 05 Oct 2009 03:54:00 GMT

可伸缩性:所谓可伸缩性，是指在小型规模单台服务器情况下，应用系统可以良好运转，系统的访问量或功能增加后，整个系统只需通过增加服务器硬件就可以实现性能扩展，无需修改太多软件。对于可伸缩性平台（如JBoss）来说，理论上，没有最大负载或最多在线人数这样的概念。

王永庆 2009-10-05 11:54 发表评论