JBossTS基础

JBossTS基础

 

JBossTS基础知识

JBossTS是基于最初纽卡斯尔大学在1986到1995开发的Arjuna系统。Arjuna支持OTS规范并且有许多OTS不具备的性能。JBossTS是OTS的扩展集：使用标准OTS接口写程序将会非常的轻便。

按照OTS规范的要求，JBossTS提供：

l         按照草案5，支持同步对象和传播上下文（PropagationContexts）。

l         支持子事务。

l         implicit context propagation where support from the ORB is available.  

l         支持多线程程序。

l         完全的分布式事务管理。举例来说，这里没有中央事务管理器，顶层事务的创建者负责其事务，不过，单独的事务管理器支持仍然是可以用的。

l         事务插入。

l         X/Open compliance, including checked transactions. This checking can optionally be disabled. Note: checked transactions are disabled by default, i.e., any thread can terminate a transaction.

l         JDBC1.0和JDBC2.0支持。

l         完整的JTA支持

有三种不同等级可以让程序员来选择使用。在接下来的部分将会简要的描述，当然，后续的章节会更详细的介绍。

注意：由于ORB实现的不同，JBossTS写成有单独的ORB可移植类库来隐藏这些差别；一些使用这种策略的例子也同样使用了该类库，因此我们推荐首先了解一下ORB可移植指南

Raw OTS

OTS实际上只是一个驱动协议在两阶段提交协议中操作注册的资源。程序编程人员负责创建并注册资源对象，资源通过持久化和同步控制来保证事务应用对象的ACID特性。程序员必须确保资源在恰当的时间注册，并且给定的资源只能注册个唯一的事务。因此，基于raw OTS级别的编程时非常的简单：程序员负责一些特定的事情，包括每个事务性对象的持久化管理和并发控制

扩展OTS功能

OTS的嵌套事务实现具有很大的局限性，可能导致启发式结果的产生：一个子事务调度者在提交过程中发现一些资源不能提交；但是它不能告诉提交的资源回滚。JBossTS允许嵌套事务执行一个完整的两阶段提交协议，这就避免了一些资源别提交的同时其它资源被回滚。

当资源注册到一个程序员无权管理的事务中，而资源会在提交/回滚协议中被调用，或者以前注册的资源需要被新注册的资源替换掉时，例如，资源注册到一个合并到上层的子事务 。JBossTS提供一个额外的资源自类型赋予程序员控制的能力。

高级程序员接口

OTS没有提供任何资源实现。这些需要程序员或者OTS实现者来提供。OTS规范中定义的接口对绝大多数的程序员来说是非常底层的。因此，伴随JBossTS的 Transactional Objects for Java，使用raw公共对象服务接口但为事务应用程序和框架提供高级API。这些API自动控制多数OTS事务中参与的行为，使得程序员可以专注于程序的开发工作，而不是事务控制。系统的结构在图2中作了展示。API与并发控制和持久化服务协作，并为事务对象自动注册恰当的资源。这些资源也会使用持久化和并发服务。

                                                                                                                                                           图 1            JBossTS 结构

JBossTS采用面向对象的方式提供给程序开发者一个java工具包，利用这个工具包应用程序类可以通过继承的方式获取想要的能力，例如并发控制和持久化。这些类是分层次的，下面展示了其中的一部分：

                                                                                                                                                         图 2            JBossTS类等级

除了指定事务的范围并设置适当的对象锁，程序开发者不需要做其他的事情：JBossTS会负责管理注册给相应事务并由其驱动的事务对象，一旦事件失败会自动调用失败恢复机制。使用这些接口开发者不需要担心创建或注册资源对象，调用持久化和并发控制服务，JBossTS将承担这些工作。如果事务是嵌套的，资源会在提交时自动传递给上层事务。

JBossTS设计和实现的初衷是为系统构建一个容错性的、分布式应用程序。在这个目标中有三个系统属性尤为重要：

l         机制整合：一个具有容错性的分布式操作系统需要一系列系统功能来支持命名，定位和调用对象的操作以及并发控制，错误侦测和失败恢复。这些机制需要整合到一起使得其使用容易而又自然。

l         灵活性：机制应该是灵活的，允许程序可以从现有实现中很容易的做出改进，例如指定类型的并发和恢复控制。

l         移植性：可以在任何ORB中使用JBossTS。

系统使用Java实现并使用类型继承来提供用户自定义对象例如持久化和恢复机制。

JBossTS 和 OTS 规范

OTS规范是使其实现在某种意义上的具有通用性，以此来满足不同应用对事务的需求。JBossTS完全支持OTS规范。另外，对规范允许用多种不同方法实现的功能，JBossTS都提供了相应实现的支持。下面简要给出了JBossTS为某些规范中选项提供的默认实现。更多信息可以在接下来的章节中获得。

OTS 规范	JBossTS 默认实现
如果事务服务选择限制事务上下文的使用，则需要抛出Unavailable异常	JBossTS没有限制事务上下文的使用
事务服务的实现不需要每次请求都要初始化事务上下文	JBossTS 只在目标对象实现TransactionalObject 接口的时候初始化事务上下文
.事务服务的实现者可以限制调度者，终结器和传递的或者在其他执行环境中的控制对象来实现事务的完整性。	JBossTS 不采取对这些对象的传播进行限制。
事务服务可能会限制开启事务的客户端中止事务的能力	JBossTS允许任何使用了Terminator接口的客户端中止事务。另外，JBossTS也没有限制使用Current接口的客户端。
使用生命周期服务的FactoryFinder接口来查找TransactionFactory。	JBossTS 提供多种方式来定位TransactionFactory 。
事务服务的实现可以使用事件服务来报告启发式决定	不使用事件服务报告启发式决定
事务不需要支持嵌套事务。	支持嵌套事务
只要事务提交就要调用对象同步.	允许事务中止时同步调用
实现的事务服务不需要支持插入	JBossTS 支持多种方式的插入

Table 2: JBossTS defaults.

线程类

JBossTS是多线程的并且支持OTS关于允许一个事务中有多个线程的建议，而且支持一个线程执行多个事务（虽然事实上同一时间之后一个事务是活跃的）。默认情况下。如果一个线程在事务范围被创建，这个新的线程不会同事务绑定。如果要将线程同事务绑定则需要使用AtomicTransaction类或当前类的resume方法。

不过，如果要求新创建的线程自动的继承父类的事物上下文，他们必须继承OTS_Thread类：

public class OTS_Thread extends Thread
{
public void terminate ();
public void run ();

protected OTS_Thread ();
};

程序员必须在应用程序线程类run方法开始的时候要调用OTS_Thread的run方法。同样的在程序线程的run方法结束前也要调用terminate方法。

public void run ()
{
    super.run();

    // do my work

    super.terminate();
}

ORB可移植性问题

虽然CORBA规范是一个标准，但它说明了实现ORB不同的方式。同样，实现可移植性的客户端和服务端是很困难的。由于JBossTS已经移植到绝大多数广泛应用的ORB中，我们可以相信我们已经遭遇过众多可能会存在的不兼容问题。同样，为了使JBossTS具有可移植性，我们开发了大量的ORB移植性类和宏。如果应用程序使用了那些类将会使其在不同的ORB中具有更好的移植性。这些类将会在单独的ORB可移植性指南（ORB Portability Manual）中做出描述。