Transactions 管理员指南
JBoss 企业级应用程序平台 5
用于 JBoss 企业级应用程序平台 5
版 5.1.0
Mark Little
mlittle@redhat.com
版权 © 2011 Red Hat, Inc
摘要
本书是适用于 JBoss 企业级应用程序平台 5 及其补丁版本的 JBoss Transactions 管理员指南。
第 1 章 介绍
JBoss Transaction 服务生成了几个管理性任务。它依赖于底层操作系统和基础结果的正常运行。作为管理员,你要记住下面的几件事情:
- JBoss Transaction 服务没有提供安全层。存储在 JBoss Transactions 的 object store 里的对象通常为运行创建这些对象的应用程序的用户所拥有。Object Store 和 Object Manager 机制没有强制对所有权的检查,Transaction Manager 也不会强制或检查对象的所有者权限。
- 除非调用
StateManager.destroy
方法或用程序显性地进行删除,对象库里创建的持久性对象不会消失。这表示对象库会积累垃圾(特别是开发和测试阶段),这会导致悬挂引用的问题。这就是说,持久性对象 A,可能以消极方式储存另外一个持久性对象 B 的 UID。但即使 A 仍然保留 B 的一个引用,这并不能阻止程序删除 B。当 A 被激活并试图访问 B 时就会产生运行错误。 - JBoss Transaction 服务目前没有对类结构改变时对象或数据库重配置的版本控制的支持。目前,如果你修改了持久性对象的类的定义,你需要完全负责确保 Object Store 里的现存实例转换成新的结构。JBoss Transactions 既不能检测也不能改正通过新的操作版本对旧的对象状态的引用,反之亦然。
- 对于事务服务来说,Object store 的管理至关重要。
第 2 章 管理 ObjectStore
在 JBoss Transaction 服务里,每当创建事务或使用 Transactional Objects for Java 时,对象库(Object Store )会定期进行更新。在无故障环境里,对象库里唯一的对象状态是哪些代表用 Transactional Objects for Java API 创建的对象的状态。
然而,如果发生了故障,事务日志可能保留在对象库里,直到故障恢复机制已经恢复了它们所代表的事务。因此,删除对象库的内容需要很小心和谨慎,这很重要,因为这会导致无法解决可疑的事务。此外,如果多个用户共享相同的对象库,他们也需明白这一点。他们不能假定对象库里的内容是独占资源而简单地进行删除。
第 3 章 OTS 和 J2EE 事务服务管理
3.1. 启动 Run-time 系统
对 JBoss Transaction 服务的运行时支持由 run-time 软件包和 OTS 事务管理服务器组成。在缺省情况下,JBoss Transaction 服务不使用独立的事务管理服务器。相反,事务管理者与每个应用程序进场共存。这消除了部分功能对其他服务的依赖,从而提高了性能和应用程序的容错能力。
如果你的应用程序要求独立的事务管理者,你可以设置
com.arjuna.ats.jts.transactionManager
环境变量为 yes
。系统用 ORB 专有的机制来定位事务管理者。它可以注册到命名服务器,添加到 ORB 的初始引用里,在 JBoss Transaction 服务专有的引用文件里列出,或者由 ORB 专有的定位机制来定位。
你可以通过设置
com.arjuna.orbportability.resolveService
环境变量为下列值来覆盖缺省的注册机制:
CONFIGURATION_FILE
,缺省值- 它使系统使用
CosServices.cfg
文件。 NAME_SERVICE
- JBoss Transaction 服务试图使用命名服务来注册事务工厂。如果 ORB 不支持,则会抛出异常。
BIND_CONNECT
- JBoss Transaction 服务使用 ORB 专有的绑定机制。如果 ORB 不支持,则会抛出异常。
RESOLVE_INITIAL_REFERENCES
- JBoss Transaction 服务试图用 ORB 的初始服务引用注册事务服务。
3.2. OTS 配置文件
和
RESOLVE_INITIAL_REFERENCES
选项类似,JBoss Transaction 服务支持初始引用文件,可以存储针对专有服务的引用并在运行时引用。这个 CosServices.cfg
文件由两个字段组成:service name
(如果使用 OTS 服务器就总是 TransactionService
)和 IOR,由空格分开。CosServices.cfg
通常位于 JBoss Transaction 服务的 etc
目录里,虽然实际的位置是通过搜索 CLASSPATH
里 etc
和 TransactionService 属性文件在运行时决定的。
如果没有找到,OTS 服务器将创建这个文件并在文件里注册自己。陈旧的信息将自动被删除。共享相同事务服务器的及其需要访问这个文件或其备份。
你可以分别用
com.arjuna.orbportability.initialReferencesFile
和 com.arjuna.orbportability.initialReferencesRoot
变量覆盖文件名称和位置。
com.arjuna.orbportability.initialReferencesFile=myFile com.arjuna.orbportability.initialReferencesRoot=c:\\temp
3.3. 命名服务
如果 ORB 支持命名服务,且 JBoss Transaction 服务已经进行了相应配置,Transaction Manager 将自动对它进行注册。
注意
这个选项不用于 JacORB
3.4. RESOLVE_INITIAL_REFERENCES
目前这个选项仅支持 JacORB。
3.5. Resolution service 表
下面的表总结了对特定 ORB 定位 OTS 事务管理者的不同方式:
表 3.1. 定位 OTS 事务管理者服务器
解析机制 | ORB |
---|---|
OTS 配置文件 | 所有可用的 ORB |
命名服务 | JacORB |
resolve_initial_references | JacORB |
第 4 章 XA 管理
JBoss Transaction 创建的每个 XA XID 都需要一个在内部编码的唯一节点标识符。JBoss Transaction 服务只能恢复事务和映射指定节点标识符的状态,这个标识符是通过
com.arjuna.ats.arjuna.xa.nodeIdentifier
属性传入 JBoss Transaction 服务的。这个值在所有的 JBoss Transaction 服务实例里必须是唯一的。如果没有设置,JBoss Transaction 服务将生成一个并通过日志架构报告这个值。
4.1. XA 恢复
在运行 XA 恢复时,JBoss Transaction 服务需被告知要恢复哪种类型的 XID。使用的节点标识符应该通过以
com.arjuna.ats.jta.xaRecoveryNode
名称开始的属性提供给 JBoss Transaction 服务。你可以传入多个值。*
值将强制 JBoss Transaction 服务恢复(也可能回滚)所有的事务,而不顾其节点标识符。使用该选项务必及其小心。
你可以在『故障和恢复』章节找到关于恢复的更多信息。
第 5 章 Web Service Transaction service 的管理
事务性 Web Services 应用程序的基本构件是:
- 应用程序本身
- 应用程序消费的 Web Service
- 事务管理者(Transaction Manager)
- 支持这些 Web 服务的事务参与者
在典型的部署里,单个开发人员不太可能支持所有这些角色。开发人员经常编写服务、或者消费服务的应用程序,而系统管理员则运行事务管理基础结构。
5.1. 事务管理者
事务管理者是一个 Web service,它协调 JBoss Transaction 服务的事务。它是 JBoss Transaction 服务里唯一的软件组件,其目的是作为网络服务直接运行,而不支持最终用户代码。事务管理者以 JAXM 请求/响应 web 服务运行。
重要
当启动其中部署有 JBoss Transaction 服务的应用程序服务器实例时,你可以在控制台或日志里看到不同的错误信息。下面是一些错误信息:
16:53:38,850 ERROR [STDERR] Message Listener Service: started, message listener jndi name activationcoordinator
这些只是提供一些信息,并非实际的错误。
5.1.1. 配置事务管理者
事务管理者和相关的基础结构是通过属性文件来配置的:
wscf.xml
wst.xml
wstx.xml
这些文件位于
conf
目录里且用于配置演示程序和 standalone 模块。
在多数情况下,这些文件里的缺省值不需要修改。然而,com.arjuna.ats.arjuna.objectstore.objectStoreDir 属性决定了用于记录事务状态的持久库的位置。
C:/temp/ObjectStore
的缺省值应该修改为适合你的系统的值。在产品环境里,这个目录应该位于容错介质里,如 RAID 阵列。
当应用程序使用独立的 coordinator 时,你必须启用并修改
wstx.xml
文件里的两个其他属性:
- com.arjuna.mw.wst.coordinatorURL
- com.arjuna.mw.wst.terminatorURL
这些属性代表着客户端应用程序用来联系独立 coordinator 的 URL。它们应该用正确的独立 coordinator 的主机名和端口进行配置。
注意
JBoss Transaction 服务是高度模块化的。为了灵活地配置个体组件,在多个配置文件里可能有相同的属性值。而对于大部分配置而言,你应该使多个文件里定义的属性保持一致。
5.1.2. 部署事务管理者
Transaction 服务的 Web Service 事务管理者组件由大量的 JAR 文件组成,它们包含应用程序的类文件以及开放必要服务的 Web service(WAR)文件。程序员在开发阶段将所有的组件都包含在 EAR 文件里,以简化事务架构的部署。在产品环境里,你可以将事务管理者安装为独立的应用程序,以在服务器级别集中配置和管理。JBoss Transaction 服务附带的演示程序包含了一个部署描述符示例,它包含了应用程序里的事务管理者组件的定义。
对于底层的协议通讯,JBoss Transaction 服务使用了固定的终端。因此,如果使用 Transaction 服务的多个应用程序都同时部署到了相同的服务器里,就会出现问题。要在相同服务器里部署多个应用服务器,可将事务管理者作为单独的应用程序部署,而不要将其嵌入到应用程序的部署里。
JBoss Transaction 服务安装里的 coordinator 目录协助配置和部署独立事务管理者。要使用它,你必须:
- 安装 JBoss 企业级应用程序平台 5
- 安装 ant 1.4 或更新版本
重要
应用服务器的安装必须和客户和服务部署位于不同位置。否则,在不同的 JBoss Transaction 服务组件间会出现冲突。
编辑 coordinator 包括的
build.xml
,使其指向事务 coordinator 将部署的应用服务器的安装位置,以及 JBoss Transaction 服务安装的位置。coordinator 的 dd/
目录里的 ws-c_jaxm_web-app.xml
and ws-t_jaxm_web-app.xml
是对应 WS-C 和 WS-T WAR 文件的部署描述符。它们包含了 URL 模板。在构建阶段,ant
将用 build.xml
里的 hostname
和 port
值替代到这些文件里。
用
target deploy-weblogic
、deploy-jboss
或 deploy-webmethods
运行ant
,以创建和部署新的 coordinator 到正确的应用服务器里。
然后,通过生成演示程序并指定 coordinator 的端口和主机名,为客户端指向所需的 coordinator。
5.1.3. 部署描述符
修改 JBoss Transaction 服务使用的不同部署描述符的内容通常不是必需的。然而,如果你确实需要进行修改,你可以在 coordinator 模块里找到它们。
不是所有的 JBoss Transaction 服务组件都可以访问部署描述符里的信息。因此,如果你修改了任何 WS-C 或 WS-T 部署描述符使用的 JNDI 名称,你可能需要在运行时通知其他 JBoss Transaction 服务组件,这是通过在
wstx.xml
文件里设置合适的属性来实现的。
表 5.1 “部署描述符的值和属性” 表显示了部署描述符使用的缺省 JNDI 名称以及在修改了缺省值时需要相应设置的属性。
表 5.1. 部署描述符的值和属性
JNDI 名称 | 属性 |
---|---|
Activationrequester | com.arjuna.mw.wst.at.activationrequester |
Activationcoordinator | com.arjuna.mw.wst.at.activationcoordinator |
Completionparticipant | com.arjuna.mw.wst.at.completionparticipant |
Registrationrequester | com.arjuna.mw.wst.at.registrationrequester |
durable2pcdispatcher | com.arjuna.mw.wst.at.durable2pcdispatcher |
durable2pcparticipant | com.arjuna.mw.wst.at.durable2pcparticipant |
volatile2pcdispatcher | com.arjuna.mw.wst.at.volatile2pcdispatcher |
volatile2pcparticipant | com.arjuna.mw.wst.at.volatile2pcparticipant |
businessagreementwithparticipantcompletiondispatcher | com.arjuna.mw.wst.ba.businessagreementwpcdispatcher |
businessagreementwithparticipantcompletionparticipant | com.arjuna.mw.wst.ba.businessagreementwpcparticipant |
businessagreementwithcoordinatorcompletiondispatcher | com.arjuna.mw.wst.ba.businessagreementwccdispatcher |
businessagreementwithcoordinatorcompletionparticipant | com.arjuna.mw.wst.ba.businessagreementwccparticipant |
第 6 章 JBoss Transactions 服务器的运行时信息
每个 JBoss Transaction 服务器模块都包含一个
Info
类。这个类提供了一个 toString
方法,它返回每个模块的配置信息的 XML dump。关于输出的例子,请参考 例 6.1 “使用 toString
方法”。
例 6.1. 使用 toString
方法
<module-info> <source-identifier>unknown</source-identifier> <build-information> Arjuna Technologies [mlittle] (Windows 2000 5.0) </build-information> <version>unknown</version> <date>2002/06/15 04:06 PM</date> <notes></notes> <configuration> <properties-file dir="null">arjuna.properties</properties-file> <object-store-root>null</object-store-root> </configuration> </module-info>
第 7 章 JBoss Transaction 服务里的资源恢复
7.1. 介绍
JBoss Transaction 服务是一个可容忍崩溃(crash tolerant)的事务管理者。在使用 XAResource 如用 <xa-datasource>, 定义的 JDBC 连接或用两阶段事务的 JBoss Messaging 的 JMS 连接时,JBoss Transaction 服务保持了一个事务日志,它允许应用服务器在事务期间崩溃后进行恢复。如果配置了合适的恢复模块,在所有资源再次可用时,大多数失败的事务可以自动恢复。
7.2. 假设
这里提及的配置选项缺省包含在
jbossts-properties.xml
文件里,它位于服务器配置下的 conf
目录里。对于使用 default 配置进行安装的 JBOSS_HOME,正确的文件路径是:JBOSS_HOME/server/default/conf/jbossts-properties.xml
。
7.3. 关于群集的注记
每个应用程序服务器实例都负责恢复它所协调的事务。通常,单个数据库服务多个应用程序服务器,因此参与来自多个协调者的事务。在恢复期间,JBoss Transaction 服务向每个应用服务器请求可能需要恢复的 in-doubt 事务列表。数据库返回所有的 in-doubt 事务,包括哪些还没有由指定实例进行协调的事务。要有效地区分每个节点的事务,你必须为共享数据库的每个应用服务器实例配置一个唯一的节点 ID,你可以设置下面的属性:
<property name="com.arjuna.ats.arjuna.xa.nodeIdentifier" value="1"/>
你也需要一个元素来指定哪些节点需要恢复。这必须和上面配置的
nodeIdentifier
相匹配。
<property name="com.arjuna.ats.jta.xaRecoveryNode" value="1"/>
7.4. 恢复模块
每个 XA 资源都需要一个对应的恢复模块,它在
jbossjta-properties.xml
里的 "jta" 部分进行配置。每个恢复模块都必须继承 com.arjuna.ats.jta.recovery.XAResourceRecovery
。我们提供用于 JDBC 和 JMS XA 资源的实现。
7.4.1. JDBC 恢复
JBoss 企业级应用程序平台现在包含了 JCA 里的恢复自动注册。因此,之前版本使用的 AppServerJDBCXARecovery 缺省是禁用的,且会在以后的版本里完全删除。
7.4.1.1. 供应商专有的数据库信息
- Oracle
- 如果没有正确地配置 Oracle,你会在日志文件里看到下面的错误:
WARN [com.arjuna.ats.jta.logging.loggerI18N] [com.arjuna.ats.internal.jta.recovery.xarecovery1] Local XARecoveryModule.xaRecovery got XA exception javax.transaction.xa.XAException, XAException.XAER_RMERR
要解决这个问题,请确保 Oracle 用户有访问合适的表的权限以完成恢复:GRANT SELECT ON sys.dba_pending_transactions TO user; GRANT SELECT ON sys.pending_trans$ TO user; GRANT SELECT ON sys.dba_2pc_pending TO user; GRANT EXECUTE ON sys.dbms_xa TO user;
上面的语句假设 user 是连接 JBoss 到 Oracle 的用户。它也假定使用的是 Oracle 10g R2(为程序错误#5945463 打了补丁) 或 11g。如果使用了 11g 之前的未打补丁的版本,你需要修改 GRANT EXECUTE 为:GRANT EXECUTE ON sys.dbms_system TO user;
- PostgreSQL
- 请参考 PostgreSQL 文档里关于启用 prepared (如 XA) 事务的说明。8.4-701 版的 PostgreSQL 的 JDBC 驱动在
org.postgresql.xa.PGXAConnection
里有一个程序错误,它在某些情况下会终止恢复。新版本里已经修复了这个问题。 - MySQL
- 根据 http://bugs.mysql.com/bug.php?id=12161 所描述的,MySQL 下 XA 事务恢复是无法实现的。MySQL 6.1 将解决这个问题。请参考 JBoss 企业级应用程序平台 5 发行注记里的 JBPAPP-2576。
- DB2
- 只有在应用服务器在崩溃/失效后重启时指定的重同步阶段,DB2 才期望
XAResource.recover
调用。这是 DB2 的一个设计缺陷,这超出了本文档的范畴。
7.4.2. JMS 恢复
请参考《JBoss Messaging 指南》里和恢复相关的内容。这些指南位于 http://docs.redhat.com 里的企业级应用程序平台文档套件里。
7.5. JMS 群集注意事项
当 JBoss Messaging 群集里的某个节点失效、它的 Buddy 将从数据库里加载所有 dead 服务器的消息。
如果在关闭时,失效节点正在执行 XA 事务,那么事务日志可能已经写入,而相关的消息将转移到群集里的其他节点上。
当失效节点恢复后,恢复管理者可能会试图恢复存储在事务日志里的事务。如果这些消息已经转移到了另外一个服务器里,那么从本地 JMS 提供者里获取正确的 XA 资源就是不可能的,这是因为相关的消息并没有位于该服务器上。结果 JBoss Transaction 服务将返回:
Could not find new XAResource to use for recovering non-serializable XAResource
要解决这个问题,为群集里的每个节点添加一个 JMS 提供者和恢复管理者(Recovery Manager)。例如,如果群集有三个节点,在
jbossts-properties.xml
里添加:
<property name="com.arjuna.ats.jta.recovery.XAResourceRecovery.JBMESSAGINGREMOTE1" value="org.jboss.jms.server.recovery.MessagingXAResourceRecovery;java:/RemoteJMSProvider1"/> <property name="com.arjuna.ats.jta.recovery.XAResourceRecovery.JBMESSAGINGREMOTE2" value="org.jboss.jms.server.recovery.MessagingXAResourceRecovery;java:/RemoteJMSProvider2"/>
在
JBOSS_HOME/server/default/deploy/jms-ds.xml
里可以配置 Remote 提供者:
<properties depends="arjuna" name="jta"> <!-- Support subtransactions in the JTA layer? Default is NO. --> <property name="com.arjuna.ats.jta.supportSubtransactions" value="NO"/> <property name="com.arjuna.ats.jta.jtaTMImplementation" value="com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionManagerImple"/> <property name="com.arjuna.ats.jta.jtaUTImplementation" value="com.arjuna.ats.internal.jta.transaction.arjunacore.UserTransactionImple"/> <!-- *** Add this line to enable recovery for JMS resources using DefaultJMSProvider *** --> <property name="com.arjuna.ats.jta.recovery.XAResourceRecovery.JBMESSAGING1" value="org.jboss.jms.server.recovery.MessagingXAResourceRecovery;java:/DefaultJMSProvider"/> </properties>
JNDI 属性用于连接群集里的远程节点。在群集里的每个节点里为所有其他节点添加提供者和恢复管理者以进行正确的恢复。
第 8 章 选择 JTA 实现
目前可通过相同的接口访问两个 JTA 实现的变种。它们是:
- 纯本地的 JTA,它只允许执行非分布式的 JTA 事务。JBoss Transactions 产品里只有这个版本可用。
- 远程的、基于 CORBA 的 JTA,它允许执行分布式的 JTA 事务。它只在 ArjunaJTS 里可用且需要对 CORBA ORB 的支持。
这两种实现都和 JBoss Transactions 提供的事务性的 JDBC 驱动完全兼容。
要选择本地的 JTA 实现,你必须执行下面的步骤:
- 设置
com.arjuna.ats.jta.jtaTMImplementation
属性为com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionManagerImple
。 - 设置
com.arjuna.ats.jta.jtaUTImplementation
属性 为com.arjuna.ats.internal.jta.transaction.arjunacore.UserTransactionImple
。
这些设置都是属性的缺省值,本地实现不需要进行指定。
第 9 章 ORB 专有的配置
JacORB
要使 JacORB 正常运行,请确保在如下地方存在有效的 jacorb.properties
或 .jacorb_properties
文件:
- CLASSPATH
- 运行 JBoss Transaction 服务的用户的主目录。其主目录可用
System.getProperty( “user.home” );
进行引用。 - 当前目录。
- 运行你的应用程序的 JDK 的
lib
目录。它用System.getProperty( “java.home” );
进行引用。
这些地方将根据列出的顺序进行搜索。在 JacORB 的安装目录下你可以找到一个
jacorb.properties
模板文件。
JacORB 属性文件包含两个重要的属性,它们必须针对应用程序正确地进行配置:
- jacorb.poa.thread_pool_max
- jacorb.poa.thread_pool_min
这些属性指定 JacORB 将在线程池里使用的最小和最大的请求处理线程的数目。如果可用的线程太少,应用程序将被死锁。关于配置 JacORB 的更多信息,请参考 JacORB 文档。
注意
JacORB 带有自己的对
CosTransactions.idl
文件里定义的类的实现。可惜的是,这些实现和 JBoss Transaction 所附带的版本并不兼容。因此,在 CLASSPATH
里, JBoss Transaction 服务 JAR 文件必须出现任何 JacORB JAR 之前 。
对于 Recovery Manager 运行的每台及其,它都必须使用相同的已知端口。你不应该使用 JacORB 提供的
OAPort
属性,除非 Recovery Manager 有自己的 jacorb.properties
文件或端口是在启动 Recovery Manager 时通过命令行指定的。如果 Recovery Manager 和 JBoss Transaction 服务的其他组件共享相同的 jacorb.properties
文件,你就应该使用 com.arjuna.ats.jts.recoveryManagerPort
和 com.arjuna.ats.jts.recoveryManagerAddress
属性。
第 10 章 初始化 JBoss Transactions 服务应用程序
在创建任何应用程序对象之前,JBoss Transaction 服务需要正确地初始化。为了确保这一点,请使用
ORB_init
和 create_POA
。
第 11 章 错误和异常
事务性应用程序运行过程中的错误和异常
- NO_MEMORY
- 应用程序已耗尽内存,抛出
OutOfMemoryError
。 JBoss Transactions 在重新抛出这个异常时已经试图进行清理(通过运行 garbage collector)。这可能是一个暂时的问题,重试应该能够成功。 - com.arjuna.ats.arjuna.exceptions.FatalError
- 表示事务系统遇到了严重错误且必须关闭。在抛出这个错误之前,服务将确保所有的事务都进行了回滚。如果捕获了这个异常,应用程序应该清理并退出。如果进行进一步尝试,可能会破坏应用程序的一致性。
- com.arjuna.ats.arjuna.exceptions.LicenceError
- 尝试以和当前许可证不一致的方式使用事务服务。事务服务将不会允许对现有的或新的事务采取进一步的行动。
- com.arjuna.ats.arjuna.exceptions.ObjectStoreError
- 事务服务试图使用 object store 时产生了错误。进一步的行动不被允许。
- 关于状态访问的 Object store 的警告
- 在失效切换的正常执行过程中,可能出现关于状态访问的 Object store 的警告。这是因为在相同的事务上执行多个并行的失效切换。它可以被忽略而无安全隐患。
附录 A. 修订记录
修订历史 | ||||
---|---|---|---|---|
修订 5.1.0-2.400 | 2013-10-31 | Rüdiger Landmann | ||
| ||||
修订 5.1.0-2 | 2012-07-18 | Anthony Towns | ||
| ||||
修订 5-1 | Wed Sep 15 2010 | Misty Stanley-Jones | ||
|