17,740
社区成员
发帖
与我相关
我的任务
分享高分求问事务处理的原理和实现途径。
小弟最近对事务处理较感兴趣。
现高分求问事务处理的原理和实现途径。
如果可能请考虑性能。
分数上没有问题我有7000分的可用分。一切好说！
现高分求问事务处理的原理和实现途径。
如果可能请考虑性能。
分数上没有问题我有7000分的可用分。一切好说！
...全文
请发表友善的回复…
发表回复
林仪明 2003-12-25
- 打赏
- 举报
下述产品提供 OTS 的实现: Integrated Transaction Service (Inprise 的产品), OrbixOTM (Iona 的产品), OTSARjuna (Arjuna Solutions Limited 的产品), 和 TPBroker (Hitachi Software 的产品).
JTS 和 JTA
Java 事务服务 和 Java 事务 API 是分布式计算领域中最新的竞争参加者。作为企业 Java 的发起者，Sun Microsystems Inc. 在 1999 年提出了规范。(译注：1999年12月8日推出正式规范)
图 3: Java 事务的发起
JTS 规定一个 Java 事务管理器的实现。这个事务管理器支持 JTA，应用服务器可以使用它建造支持事务性 Java 的应用。 JTS 的内部实现 OMG OTS 1.1 规范的 Java 映射。Java 映射被规定在两个包中: org.omg.CosTransactions 和 org.omg.CosTSPortability。尽管 JTS 是 OMG OTS 1.1 规范的一个 Java 实现，JTA 仍是简化了的 X/Open DTP 模型中的 XA 和 TX 的函数形式的接口。
JTA 规定一个建造事务性应用服务器的体系，并为这个体系中各种构件定一系列的接口。 这些构件是: 应用构件, 资源管理器, 应用服务器, 它们在 图 3 中展示。
JTS 为事务性应用服务器和应用提供了一个新的体系，而在内部遵从 OMG OTS 1.1 接口。这就允许遵从 JTA 的应用程序同其他的遵从 OTS 1.1 的应用程序通过标准的 IIOP 来互操作。
象在 图 3 中展示的那样，在 Java 事务模型中，Java 应用构件能通过 JTS 在遵从 JTA 的资源上指挥事务性操作。JTS 扮演的是 OTS 之上的一个薄层。应用可以发起全局事务来包含其他 OTS 事务管理器，或参与到一个其他遵从 OTS 的事务管理器发起的全局事务。
关于 JTS 和 JTA 的更详细的叙述请参见 Java 事务服务。
--------------------------------------------------------------------------------
Microsoft 事务服务器
Microsoft 事务服务器(MTS) 是一个基于构件的事务服务器，它的构件基于 Microsoft 的 构件对象模型 (COM)。MTS 编程模型为建造事务性 COM 构件提供接口，而 MTS 运行环境提供一个部署和管理这些构件和管理事务的方法。使用了 MTS，由多个 COM 构件做的工作可被组合在一个单一的事务中。
不象本章讨论的其他技术，MTS 是一个产品并且不基于开放的规范。还要注意，尽管 MTS 环境提供了一些其他特征，如资源缓冲池(pooling), 对象重复利用(recycling), 访问控制等，本节只聚焦于 MTS 的事务性的功能，并尝试把各种事务管理的概念映射到 MTS 环境。
MTS 体系
高层的 MTS 体系在 图 4 中展示：
图 4: Microsoft 事务服务器
MTS 环境由下列部分组成:
MTS 运行时环境(run-time): 它是 MTS 构件的实例执行和被管理的环境。 MTS 运行时环境提供了 MTS 构件的部署和管理。它有以下特征:
分布式事务的管理
过程和线程的原子性管理
对象的(建立，缓冲(pooling)和重用)管理
控制对象的建立和使用的分布式安全服务
MTS Explorer: 这是一个图形用户界面驱动的工具，用来在 MTS 运行环境上部署和管理 MTS 构件。MTS Explorer 也被用于通过分布式事务协调器来监控事务。
分布式事务协调器(DTC): DTC 是 MTS 的事务管理器。
MTS API: MTS API (在 Microsoft Visual Basic， Microsoft Visual C++ 和 Microsoft Visual J++ 中) 为建造事务性构件提供特定的接口和特定的具体的类。
资源分发器(dispenser): 一个 MTS 资源分发器代表 MTS 应用来管理非持久的共享的数据。MTS 提供两个资源分发器:
ODBC 资源分发器: ODBC 资源分发器本质上是一个 ODBC 驱动器的管理器，并有下列附加功能 :
管理到遵从 ODBC 的数据库的连接的缓冲池，包括连接的回收和重用。
征集和遣散在 MTS 上下文对象上的数据库连接。
共享的属性管理器: MTS 共享的属性管理器管理应用范围的特定于进程的属性(一对名字-值) 并提供同步的访问这个数据。
资源管理器: 对于一个参与 MTS 事务的资源管理器，它必须支持下列协议之一:
OLE 事务: 这是一个基于 COM 的两阶段提交协议，资源管理器使用它来参与由 DTC 协调的事务。
X/Open DTP XA 协议: 对于这个协议，MTS 要求一个 OLE 事务到 XA 的映射器(mapper)。这个映射器在 MTS SDK 中提供。
MTS 对象和事务上下文
一个 MTS 对象是一个 MTS 构件的一个实例(一个构件在 MTS 上被部署，并被 MTS 管理)。对于每个 MTS 对象，MTS 建立和维护一个上下文对象(ObjectContext)，它为一个 MTS 对象提供执行上下文。上下文对象也维护事务上下文的信息。资源分发器和 DTC 可以为事务界定，资源征集，遣散，两阶段提交等，访问这个事务上下文信息。注意，在 MTS 中，为每个 MTS 对象都维护事务上下文信息，而不是为所有参与一个事务的对象维护一个单一的事务上下文对象。
事务结果
每个 MTS 对象可以通过调用 ObjectContext 对象的一个方法，来参与决定一个事务的结果(outcome):
SetComplete: 通知 MTS，对象已经成功的完成了它的工作，它的工作可以被提交了。
SetAbort: 通知 MTS，对象的工作不能被提交。
EnableCommit: 对象的工作不是必须做完，但它的事务性工作可以用当前的形式被提交。
DisableCommit: 通知 MTS，对象的工作不能用当前的形式被提交。
事务界定
MTS 同时允许事务的编程界定和声明界定。对于在 MTS 上部署构件，声明界定是强制的。除此之外，MTS 客户也可以通过编程发起和结束事务。
声明界定: 依靠一个 MTS 构件的事务属性(property)，MTS 代表应用自动的开始一个事务。可能以有下列的事务属性 (可以在部署期间设置):
要求事务: 构件的实例总是在一个事务的上下文中执行。希望调用(调用)对象在一个事务的上下文中被执行。
要求新事务: 构件的实例必须在它们自己的事务中执行，而不考虑调用对象是否已经开始了一个事务。
支持事务: 构件的实例可以在调用对象的事务(如果有的话)范围内执行。这暗示构件是事务安全的。
不支持事务: 构件的实例不在任何事务的范围内执行。MTS 不把这样的构件做的工作同任何事务关联在一起。
编程界定: MTS 客户可以使用 TransactionContext 对象用程序界定事务。一个客户可以通过建立TransactionContext 对象的一个实例来开始一个事务，并通过调用这个对象的 Commit 或 Abort 方法来结束事务。所有在这些使用 TransactionContext 对象的边界内建立的 MTS 对象将在同一个事务上下文下执行。(除非构件设置为要求一个新事务或不支持事务)。 MTS 隐含的维护 TransactionContext 对象和事务的关联。
资源征集
MTS 进行自动的资源征集。当一个 MTS 对象向资源分发器要求到一个资源的连接时，资源分发器获取调用对象的事务上下文，并用来它注册连接。
经管 MTS 只能在 Microsoft Windows 平台上获得，MTS 可以同遵循 XA 协议的资源管理器互操作，并且在非 Windows 平台上操作的这样的资源管理器可以参与由 DTC 协调的事务。
关于 MTS 的更多的信息请参阅 MSDN library。 要得到 MTS 和其他竞争技术的一个快速而详细的特征汇编请参阅 MTS FAQ.
JTS 和 JTA
Java 事务服务 和 Java 事务 API 是分布式计算领域中最新的竞争参加者。作为企业 Java 的发起者，Sun Microsystems Inc. 在 1999 年提出了规范。(译注：1999年12月8日推出正式规范)
图 3: Java 事务的发起
JTS 规定一个 Java 事务管理器的实现。这个事务管理器支持 JTA，应用服务器可以使用它建造支持事务性 Java 的应用。 JTS 的内部实现 OMG OTS 1.1 规范的 Java 映射。Java 映射被规定在两个包中: org.omg.CosTransactions 和 org.omg.CosTSPortability。尽管 JTS 是 OMG OTS 1.1 规范的一个 Java 实现，JTA 仍是简化了的 X/Open DTP 模型中的 XA 和 TX 的函数形式的接口。
JTA 规定一个建造事务性应用服务器的体系，并为这个体系中各种构件定一系列的接口。 这些构件是: 应用构件, 资源管理器, 应用服务器, 它们在 图 3 中展示。
JTS 为事务性应用服务器和应用提供了一个新的体系，而在内部遵从 OMG OTS 1.1 接口。这就允许遵从 JTA 的应用程序同其他的遵从 OTS 1.1 的应用程序通过标准的 IIOP 来互操作。
象在 图 3 中展示的那样，在 Java 事务模型中，Java 应用构件能通过 JTS 在遵从 JTA 的资源上指挥事务性操作。JTS 扮演的是 OTS 之上的一个薄层。应用可以发起全局事务来包含其他 OTS 事务管理器，或参与到一个其他遵从 OTS 的事务管理器发起的全局事务。
关于 JTS 和 JTA 的更详细的叙述请参见 Java 事务服务。
--------------------------------------------------------------------------------
Microsoft 事务服务器
Microsoft 事务服务器(MTS) 是一个基于构件的事务服务器，它的构件基于 Microsoft 的 构件对象模型 (COM)。MTS 编程模型为建造事务性 COM 构件提供接口，而 MTS 运行环境提供一个部署和管理这些构件和管理事务的方法。使用了 MTS，由多个 COM 构件做的工作可被组合在一个单一的事务中。
不象本章讨论的其他技术，MTS 是一个产品并且不基于开放的规范。还要注意，尽管 MTS 环境提供了一些其他特征，如资源缓冲池(pooling), 对象重复利用(recycling), 访问控制等，本节只聚焦于 MTS 的事务性的功能，并尝试把各种事务管理的概念映射到 MTS 环境。
MTS 体系
高层的 MTS 体系在 图 4 中展示：
图 4: Microsoft 事务服务器
MTS 环境由下列部分组成:
MTS 运行时环境(run-time): 它是 MTS 构件的实例执行和被管理的环境。 MTS 运行时环境提供了 MTS 构件的部署和管理。它有以下特征:
分布式事务的管理
过程和线程的原子性管理
对象的(建立，缓冲(pooling)和重用)管理
控制对象的建立和使用的分布式安全服务
MTS Explorer: 这是一个图形用户界面驱动的工具，用来在 MTS 运行环境上部署和管理 MTS 构件。MTS Explorer 也被用于通过分布式事务协调器来监控事务。
分布式事务协调器(DTC): DTC 是 MTS 的事务管理器。
MTS API: MTS API (在 Microsoft Visual Basic， Microsoft Visual C++ 和 Microsoft Visual J++ 中) 为建造事务性构件提供特定的接口和特定的具体的类。
资源分发器(dispenser): 一个 MTS 资源分发器代表 MTS 应用来管理非持久的共享的数据。MTS 提供两个资源分发器:
ODBC 资源分发器: ODBC 资源分发器本质上是一个 ODBC 驱动器的管理器，并有下列附加功能 :
管理到遵从 ODBC 的数据库的连接的缓冲池，包括连接的回收和重用。
征集和遣散在 MTS 上下文对象上的数据库连接。
共享的属性管理器: MTS 共享的属性管理器管理应用范围的特定于进程的属性(一对名字-值) 并提供同步的访问这个数据。
资源管理器: 对于一个参与 MTS 事务的资源管理器，它必须支持下列协议之一:
OLE 事务: 这是一个基于 COM 的两阶段提交协议，资源管理器使用它来参与由 DTC 协调的事务。
X/Open DTP XA 协议: 对于这个协议，MTS 要求一个 OLE 事务到 XA 的映射器(mapper)。这个映射器在 MTS SDK 中提供。
MTS 对象和事务上下文
一个 MTS 对象是一个 MTS 构件的一个实例(一个构件在 MTS 上被部署，并被 MTS 管理)。对于每个 MTS 对象，MTS 建立和维护一个上下文对象(ObjectContext)，它为一个 MTS 对象提供执行上下文。上下文对象也维护事务上下文的信息。资源分发器和 DTC 可以为事务界定，资源征集，遣散，两阶段提交等，访问这个事务上下文信息。注意，在 MTS 中，为每个 MTS 对象都维护事务上下文信息，而不是为所有参与一个事务的对象维护一个单一的事务上下文对象。
事务结果
每个 MTS 对象可以通过调用 ObjectContext 对象的一个方法，来参与决定一个事务的结果(outcome):
SetComplete: 通知 MTS，对象已经成功的完成了它的工作，它的工作可以被提交了。
SetAbort: 通知 MTS，对象的工作不能被提交。
EnableCommit: 对象的工作不是必须做完，但它的事务性工作可以用当前的形式被提交。
DisableCommit: 通知 MTS，对象的工作不能用当前的形式被提交。
事务界定
MTS 同时允许事务的编程界定和声明界定。对于在 MTS 上部署构件，声明界定是强制的。除此之外，MTS 客户也可以通过编程发起和结束事务。
声明界定: 依靠一个 MTS 构件的事务属性(property)，MTS 代表应用自动的开始一个事务。可能以有下列的事务属性 (可以在部署期间设置):
要求事务: 构件的实例总是在一个事务的上下文中执行。希望调用(调用)对象在一个事务的上下文中被执行。
要求新事务: 构件的实例必须在它们自己的事务中执行，而不考虑调用对象是否已经开始了一个事务。
支持事务: 构件的实例可以在调用对象的事务(如果有的话)范围内执行。这暗示构件是事务安全的。
不支持事务: 构件的实例不在任何事务的范围内执行。MTS 不把这样的构件做的工作同任何事务关联在一起。
编程界定: MTS 客户可以使用 TransactionContext 对象用程序界定事务。一个客户可以通过建立TransactionContext 对象的一个实例来开始一个事务，并通过调用这个对象的 Commit 或 Abort 方法来结束事务。所有在这些使用 TransactionContext 对象的边界内建立的 MTS 对象将在同一个事务上下文下执行。(除非构件设置为要求一个新事务或不支持事务)。 MTS 隐含的维护 TransactionContext 对象和事务的关联。
资源征集
MTS 进行自动的资源征集。当一个 MTS 对象向资源分发器要求到一个资源的连接时，资源分发器获取调用对象的事务上下文，并用来它注册连接。
经管 MTS 只能在 Microsoft Windows 平台上获得，MTS 可以同遵循 XA 协议的资源管理器互操作，并且在非 Windows 平台上操作的这样的资源管理器可以参与由 DTC 协调的事务。
关于 MTS 的更多的信息请参阅 MSDN library。 要得到 MTS 和其他竞争技术的一个快速而详细的特征汇编请参阅 MTS FAQ.
林仪明 2003-12-25
- 打赏
- 举报
下面的章节讨论事务处理相关的各种概念。
事务处理 - 概念
事务界定
指定一个事务叫做事务界定(demarcation)，通过把分布式的构件绑定到一个全局事务上来完成事务界定工作，它是标记构成一个事务的一组操作的一种方法。
最常用的界定的途径是为事务处理标记执行操作的线程。这叫做编程界定。这样建立的事务可以通过去除标记而被挂起，并在以后通过从挂起点向恢复点显式的传播事务上下文来恢复执行。
事务界定在向事务管理器的一个提交或一个回滚请求之后结束。提交请求指导所有参与的资源管理器永久的记录事务中的操作的效果。回滚请求使资源管理器撤消事务中所有操作的效果。
一个可替代编程界定的是声明界定。基于构件的事务处理系统如 Microsoft 事务服务器、和基于应用服务器的事务处理系统如企业 Java Beans 规范支持声明界定。在这种技术中，构件在部署时被标记为事务性的。这暗示了两件事。首先，界定的职责从应用转移到了容纳构件的容器(container)。为此，这种技术也叫做管理容器界定。其次，界定从应用建造期间(静态)延期到构件部署期间(动态)。
事务上下文和传播
因为多个应用构件和资源参与了一个事务，对于事务管理器建立和维护发生的事务的状态是必须的。这通常以事务上下文的形式完成。
事务上下文是在资源上的事务性操作和调用操作的构件之间的一个关联(association)。在一个事务执行期间，所有的参与事务的线程共享事务上下文。所以事务上下文在逻辑上封装(envelop)了在一个事务期间在事务性资源上的完成的所有操作。事务上下文通常由底层的事务管理器透明的维护。
资源征集
资源征集是资源管理器向事务管理器报告它们参与一个事务的过程。这个过程使事务管理器可以跟踪参与一个事务的所有资源。资源管理器使用这些信息协调资源管理器完成的事务性工作，以及驱动两阶段提交和恢复协议。
在事务结束时(一个提交或回滚之后)事务管理器遣散资源。在此之后，不再保持事务与资源之间的关联。
两阶段提交
这个事务管理器与所有应征一个事务的资源之间的协议确定是所有的资源管理器都提交事务还是它们都终止(abort)。在这个协议中，当应用要求提交事务时，事务管理器向所有涉及的资源管理器发起一个准备请求 。每个这些资源可以依次发送一个回应来指示出它是否准备好(就绪)提交。只有当所有的资源管理器都准备好提交，事务管理器才向所有的资源管理器发起一个提交请求。否则， 事务管理器发起一个回滚请求接着事务被滚回来。
--------------------------------------------------------------------------------
事务处理 - 标准和技术
X/Open 分布式事务处理模型
X/Open 分布式事务处理(DTP)模型是 Open Group 提出的一个分布式处理模型，Open Group 是一个厂商财团。这个模型是在事务处理和数据库领域中多数商业厂商间的一个标准。
这个模型由四个构件组成:
应用程序：实现事务性操作。
资源管理器：同于上面的讨论。
事务管理器：同于上面的讨论。
通信资源管理器：方便在不同的事务处理领域中的不同的事务管理器之间的互操作。
这个模型还定义了下列接口:
TX 接口: 这是应用程序和事务管理器之间的接口，并由事务管理器实现。这个接口提供事务界定服务，允许应用程序把事务性操作绑定到一个全局事务中。这个接口由下列函数组成:
函数 功能
tx_open 打开一个事务管理器和相关联的一组资源管理器。
tx_close 关闭一个事务管理器和相关联的一组资源管理器。
tx_begin 开始一个新事务。
tx_rollback 回滚事务。
tx_commit 提交事务。
tx_set_commit_return 提交事务。(译注：原文如是)
tx_set_transaction_control 在链状和非链状模式间选择。在链状事务的情况下，工作被分成片段(piece)，每个片段在一个平坦的(flat)事务控制之下。一旦完成了工作的一个片段，这个片段的提交或回滚不依赖于其他的片段的状态。
tx_set_transaction_timeout 设置一个事务超时间隔。
tx_info 返回事务信息，如它的标识符、事务的状态等。
表 1: X/Open 模型的 TX 接口
XA 接口: 这是一个资源管理器和事务管理器之间的双向接口。这个接口规定了两套函数。第一套叫 xa_*() 函数，由资源管理器实现，被事务管理器使用。
函数 功能
xa_start 指导一个资源管理器把应用程序的后续的请求与一个被提供的标识符所标识的事务关联起来。
xa_end 结束一个资源管理器与一个事务的关联。
xa_prepare 资源管理器为提交操作做准备。由事务管理器发起，是两阶段提交操作的第一阶段。
xa_commit 提交事务性操作。由事务管理器发起，是两阶段提交操作的第二阶段。
xa_recover 检索一个就绪的(prepared)列表，启发式的(heuristically)提交或启发式的回滚事务。
xa_forget 忘记同给定事务标识符相关联的启发式(heuristic)事务。
表 2: X/Open DTP 模型中的事务管理器的 XA 接口
第二套函数叫 ax_*() 函数，由事务管理器实现，被资源管理器使用。
函数
功能
ax_reg
动态的向一个事务管理器应征。
ax_unreg
动态的从一个事务管理器撤出。
表 3: X/Open DTP 模型中的资源管理器的 AX 接口
XA+ 接口: 这个接口被用于支持通过通信资源管理器来跨越不同的事务管理器的全局事务。
TXRPC 接口: 这个接口提供在一个全局事务中的不同的应用程序之间通信的可移植性。
CRM-OSI TP: 是一个通信资源管理器和 OSI 事务处理服务之间的接口。
X/Open DTP 模型在产业界中被确立的。一些商业事务管理产品，象 TXSeries/Encina (完全附属于 IBM 的 Tranarc 的产品), Tuxedo 和 TopEnd (BEA Systems 的产品), 还有 AT&T GIS 支持 TX 接口。尽管 Microsoft 的 Transaction Server 不支持 TX 接口，它还是能够同象 Oracle 这样的遵从 XA 的数据库互操作。类似的，多数商业数据库象 Oracle, Sybase, Informix 和 Microsoft SQL Server, 以及消息中间件产品如 IBM 的 MQSeries, 和 Microsoft 的 MSMQ Server 提供了 XA 接口的一个实现。
OMG 对象事务服务
对象事务服务(OTS)是由对象管理组织(OMG)规定的分布式事务处理服务。这个规范扩展了 CORBA 模型并定义了一系列跨越(across)多个 CORBA 对象完成事务处理的接口。
OTS 模型基于 X/Open DTP 模型之上并提供下列增强:
OTS 模型把函数形式的 XA 和 TX 接口替换成了 CORBA IDL 接口。
在这个模型中的各种对象通过在 IIOP 之上的 CORBA 方法调用来通信。
OTS 可以同 X/Open DTP 模型互操作。一个使用了事务性对象的应用可以使用事务管理器的 TX 接口来进行事务界定。
OTS 体系由下列构件组成:
事务客户: 一个调用事务性对象上的操作的程序或对象。
事务性对象: 一个封装(encapsulate)或参照(refers to)持久数据的 CORBA 对象，并且它的行为依赖于在一个事务期间是否调用它的操作。
可恢复对象: 一个直接维护持久数据并且参与事务协议的事务性对象。
事务性服务器: 一个或多个事务性对象的集合(collection)。
可恢复服务器: 一个对象的集合，其中至少有一个是可恢复的。
资源对象: 一个资源对象是为了参与两阶段提交和恢复协议而被注册的、在事务服务中的一个对象。
除了通常的事务性语义，CORBA OTS 还提供了下面的:
嵌套事务: 这就允许一个应用建立一个嵌入在一个现存的事务中的事务。在这个模型中，多个子事务(subtransaction)可以递归的嵌入一个事务中。子事务可以提交或回滚而不提交或回滚它的父事务。 但是，一个提交操作的结果要视事务的所有祖先的提交(commitment)状况而定。这个模型的主要优点是可以在一个精细的粒度上控制事务性操作。应用有一个在子事务层次上对错误进行改正或补偿的机会，而不用真正的去尝试提交整个父事务。
应用同步: 使用 OTS 同步协议，在两阶段提交过程开始之前和完成之后，特定的对象可以为了通告而被注册在事务服务上。这使得应用对象可以同步暂时的(transient)状态和存储在持久存储中的数据。
图 6: ORBacus® OTS 体系 (译者添加)
下面是 CORBA OTS 规范的原理上的接口：
接口 职责
Current 事务界定 (begin, commit, rollback, rollback_only, set_time_out)
事务的状态 (get_status)
事务的名字 (get_transaction_name)
事务上下文 (get_control)
TransactionFactory 显式的事务建立
Control 显式的事务上下文管理
Terminator 提交或回滚一个事务
Coordinator 事务的状态 (get_status, get_parent_status, get_top_level_status)
事务的信息 (is_same_transaction, is_related_transaction, is_ancestor_transaction, is_descendant_transaction, is_top_level_transaction, hash_transaciton, hash_top_level_transaction, get_transaction_name, get_txcontext)
资源征集 (register_resource, register_subtrans_aware)
同步对象的注册 (register_synchronization)
为回滚而设置对象 (rollback_only)
建立子事务 (create_subtransaction)
RecoveryCoordinator 在失败的情况下协调恢复 (replay_completion)
Resource 参与两阶段提交和恢复协议 (prepare, rollback, commit, commit_one_phase, forget)
Synchronization 在两阶段提交开始之前和完成之后的应用同步 (before_completion, after_completion)
SubtransactionAwareResource 提交或回滚一个子事务 ，被事务服务调用 (commit_subtransaction, rollback_subtransaction)
TransactionalObject 所有事务性对象都实现的一个指示器(marker)接口
事务处理 - 概念
事务界定
指定一个事务叫做事务界定(demarcation)，通过把分布式的构件绑定到一个全局事务上来完成事务界定工作，它是标记构成一个事务的一组操作的一种方法。
最常用的界定的途径是为事务处理标记执行操作的线程。这叫做编程界定。这样建立的事务可以通过去除标记而被挂起，并在以后通过从挂起点向恢复点显式的传播事务上下文来恢复执行。
事务界定在向事务管理器的一个提交或一个回滚请求之后结束。提交请求指导所有参与的资源管理器永久的记录事务中的操作的效果。回滚请求使资源管理器撤消事务中所有操作的效果。
一个可替代编程界定的是声明界定。基于构件的事务处理系统如 Microsoft 事务服务器、和基于应用服务器的事务处理系统如企业 Java Beans 规范支持声明界定。在这种技术中，构件在部署时被标记为事务性的。这暗示了两件事。首先，界定的职责从应用转移到了容纳构件的容器(container)。为此，这种技术也叫做管理容器界定。其次，界定从应用建造期间(静态)延期到构件部署期间(动态)。
事务上下文和传播
因为多个应用构件和资源参与了一个事务，对于事务管理器建立和维护发生的事务的状态是必须的。这通常以事务上下文的形式完成。
事务上下文是在资源上的事务性操作和调用操作的构件之间的一个关联(association)。在一个事务执行期间，所有的参与事务的线程共享事务上下文。所以事务上下文在逻辑上封装(envelop)了在一个事务期间在事务性资源上的完成的所有操作。事务上下文通常由底层的事务管理器透明的维护。
资源征集
资源征集是资源管理器向事务管理器报告它们参与一个事务的过程。这个过程使事务管理器可以跟踪参与一个事务的所有资源。资源管理器使用这些信息协调资源管理器完成的事务性工作，以及驱动两阶段提交和恢复协议。
在事务结束时(一个提交或回滚之后)事务管理器遣散资源。在此之后，不再保持事务与资源之间的关联。
两阶段提交
这个事务管理器与所有应征一个事务的资源之间的协议确定是所有的资源管理器都提交事务还是它们都终止(abort)。在这个协议中，当应用要求提交事务时，事务管理器向所有涉及的资源管理器发起一个准备请求 。每个这些资源可以依次发送一个回应来指示出它是否准备好(就绪)提交。只有当所有的资源管理器都准备好提交，事务管理器才向所有的资源管理器发起一个提交请求。否则， 事务管理器发起一个回滚请求接着事务被滚回来。
--------------------------------------------------------------------------------
事务处理 - 标准和技术
X/Open 分布式事务处理模型
X/Open 分布式事务处理(DTP)模型是 Open Group 提出的一个分布式处理模型，Open Group 是一个厂商财团。这个模型是在事务处理和数据库领域中多数商业厂商间的一个标准。
这个模型由四个构件组成:
应用程序：实现事务性操作。
资源管理器：同于上面的讨论。
事务管理器：同于上面的讨论。
通信资源管理器：方便在不同的事务处理领域中的不同的事务管理器之间的互操作。
这个模型还定义了下列接口:
TX 接口: 这是应用程序和事务管理器之间的接口，并由事务管理器实现。这个接口提供事务界定服务，允许应用程序把事务性操作绑定到一个全局事务中。这个接口由下列函数组成:
函数 功能
tx_open 打开一个事务管理器和相关联的一组资源管理器。
tx_close 关闭一个事务管理器和相关联的一组资源管理器。
tx_begin 开始一个新事务。
tx_rollback 回滚事务。
tx_commit 提交事务。
tx_set_commit_return 提交事务。(译注：原文如是)
tx_set_transaction_control 在链状和非链状模式间选择。在链状事务的情况下，工作被分成片段(piece)，每个片段在一个平坦的(flat)事务控制之下。一旦完成了工作的一个片段，这个片段的提交或回滚不依赖于其他的片段的状态。
tx_set_transaction_timeout 设置一个事务超时间隔。
tx_info 返回事务信息，如它的标识符、事务的状态等。
表 1: X/Open 模型的 TX 接口
XA 接口: 这是一个资源管理器和事务管理器之间的双向接口。这个接口规定了两套函数。第一套叫 xa_*() 函数，由资源管理器实现，被事务管理器使用。
函数 功能
xa_start 指导一个资源管理器把应用程序的后续的请求与一个被提供的标识符所标识的事务关联起来。
xa_end 结束一个资源管理器与一个事务的关联。
xa_prepare 资源管理器为提交操作做准备。由事务管理器发起，是两阶段提交操作的第一阶段。
xa_commit 提交事务性操作。由事务管理器发起，是两阶段提交操作的第二阶段。
xa_recover 检索一个就绪的(prepared)列表，启发式的(heuristically)提交或启发式的回滚事务。
xa_forget 忘记同给定事务标识符相关联的启发式(heuristic)事务。
表 2: X/Open DTP 模型中的事务管理器的 XA 接口
第二套函数叫 ax_*() 函数，由事务管理器实现，被资源管理器使用。
函数
功能
ax_reg
动态的向一个事务管理器应征。
ax_unreg
动态的从一个事务管理器撤出。
表 3: X/Open DTP 模型中的资源管理器的 AX 接口
XA+ 接口: 这个接口被用于支持通过通信资源管理器来跨越不同的事务管理器的全局事务。
TXRPC 接口: 这个接口提供在一个全局事务中的不同的应用程序之间通信的可移植性。
CRM-OSI TP: 是一个通信资源管理器和 OSI 事务处理服务之间的接口。
X/Open DTP 模型在产业界中被确立的。一些商业事务管理产品，象 TXSeries/Encina (完全附属于 IBM 的 Tranarc 的产品), Tuxedo 和 TopEnd (BEA Systems 的产品), 还有 AT&T GIS 支持 TX 接口。尽管 Microsoft 的 Transaction Server 不支持 TX 接口，它还是能够同象 Oracle 这样的遵从 XA 的数据库互操作。类似的，多数商业数据库象 Oracle, Sybase, Informix 和 Microsoft SQL Server, 以及消息中间件产品如 IBM 的 MQSeries, 和 Microsoft 的 MSMQ Server 提供了 XA 接口的一个实现。
OMG 对象事务服务
对象事务服务(OTS)是由对象管理组织(OMG)规定的分布式事务处理服务。这个规范扩展了 CORBA 模型并定义了一系列跨越(across)多个 CORBA 对象完成事务处理的接口。
OTS 模型基于 X/Open DTP 模型之上并提供下列增强:
OTS 模型把函数形式的 XA 和 TX 接口替换成了 CORBA IDL 接口。
在这个模型中的各种对象通过在 IIOP 之上的 CORBA 方法调用来通信。
OTS 可以同 X/Open DTP 模型互操作。一个使用了事务性对象的应用可以使用事务管理器的 TX 接口来进行事务界定。
OTS 体系由下列构件组成:
事务客户: 一个调用事务性对象上的操作的程序或对象。
事务性对象: 一个封装(encapsulate)或参照(refers to)持久数据的 CORBA 对象，并且它的行为依赖于在一个事务期间是否调用它的操作。
可恢复对象: 一个直接维护持久数据并且参与事务协议的事务性对象。
事务性服务器: 一个或多个事务性对象的集合(collection)。
可恢复服务器: 一个对象的集合，其中至少有一个是可恢复的。
资源对象: 一个资源对象是为了参与两阶段提交和恢复协议而被注册的、在事务服务中的一个对象。
除了通常的事务性语义，CORBA OTS 还提供了下面的:
嵌套事务: 这就允许一个应用建立一个嵌入在一个现存的事务中的事务。在这个模型中，多个子事务(subtransaction)可以递归的嵌入一个事务中。子事务可以提交或回滚而不提交或回滚它的父事务。 但是，一个提交操作的结果要视事务的所有祖先的提交(commitment)状况而定。这个模型的主要优点是可以在一个精细的粒度上控制事务性操作。应用有一个在子事务层次上对错误进行改正或补偿的机会，而不用真正的去尝试提交整个父事务。
应用同步: 使用 OTS 同步协议，在两阶段提交过程开始之前和完成之后，特定的对象可以为了通告而被注册在事务服务上。这使得应用对象可以同步暂时的(transient)状态和存储在持久存储中的数据。
图 6: ORBacus® OTS 体系 (译者添加)
下面是 CORBA OTS 规范的原理上的接口：
接口 职责
Current 事务界定 (begin, commit, rollback, rollback_only, set_time_out)
事务的状态 (get_status)
事务的名字 (get_transaction_name)
事务上下文 (get_control)
TransactionFactory 显式的事务建立
Control 显式的事务上下文管理
Terminator 提交或回滚一个事务
Coordinator 事务的状态 (get_status, get_parent_status, get_top_level_status)
事务的信息 (is_same_transaction, is_related_transaction, is_ancestor_transaction, is_descendant_transaction, is_top_level_transaction, hash_transaciton, hash_top_level_transaction, get_transaction_name, get_txcontext)
资源征集 (register_resource, register_subtrans_aware)
同步对象的注册 (register_synchronization)
为回滚而设置对象 (rollback_only)
建立子事务 (create_subtransaction)
RecoveryCoordinator 在失败的情况下协调恢复 (replay_completion)
Resource 参与两阶段提交和恢复协议 (prepare, rollback, commit, commit_one_phase, forget)
Synchronization 在两阶段提交开始之前和完成之后的应用同步 (before_completion, after_completion)
SubtransactionAwareResource 提交或回滚一个子事务 ，被事务服务调用 (commit_subtransaction, rollback_subtransaction)
TransactionalObject 所有事务性对象都实现的一个指示器(marker)接口
林仪明 2003-12-25
- 打赏
- 举报
介绍
事务管理是对企业应用最紧要的要求之一。在贸易、金融和电子商业领域中，多数大的企业应用依赖于递送它们的商务的事务处理功能。 鉴于当今商务对灵活性的要求，在建造、部署和维护企业级别的分布式应用中，事务处理占据的是其中最复杂的部分之一。
本文把以下内容介绍给读者:
什么是事务? 什么是 ACID?
建造一个事务应用的要点是什么? 事务管理中间件为什么很重要?
事务处理应用的典型的体系是怎样的? 体系中的各种构件的职责是什么?
事务处理系统涉及哪些概念?
事务管理领域中有哪些标准和技术?
本文不特定于任何产品，力图在描述各种要点和概念时保持普遍性。本文不打算比较各种事务处理的技术/标准，只是提供对此的一个讨论。
--------------------------------------------------------------------------------
什么是事务?
为了完成对数据的操作，企业应用经常要求并发访问在多个构件之间共享的数据。这些应用在下列条件下应该维护数据的完整性(由应用的商务规则来定义):
分布式访问一个单独的数据资源，以及
从一个单独的应用构件访问分布式资源。
在这种情况，可能要求在(分布式)资源上的一组操作被当作一个工作单元(unit)。在一个工作单元中, 操作的所有部分一起成功或失败并恢复。在下面的情况下这个问题更加复杂:
通过一组分布式的、访问多个资源的数据的构件实现一个工作单元，和/或
部分操作是被顺序执行的或在要求协调和/或同步的并行线程中。
在所有情况下, 都要求应用维护一个工作单元的成功或失败。在失败的情况下，所有资源要把数据状态返回到以前的状态 (比如说，工作单元开始前的状态)。
事务的概念和和事务管理器(或者一个事务处理服务)在一个工作单元中的维护数据完整性，这就简化了这样的企业级别分布式应用的构造。
一个事务是有下列属性的一个工作单元:
原子性(ATOMICITY): 一个事务要被完全的无二义性的做完或撤消。在任何操作出现一个错误的情况下，构成事务的所有操作的效果必须被撤消，数据应被回滚到以前的状态。
一致性(CONSISTENCY): 一个事务应该保护所有定义在数据上的不变的属性(例如完整性约束)。在完成了一个成功的事务时，数据应处于一致的状态。换句话说，一个事务应该把系统从一个一致状态转换到另一个一致状态。举个例子，在关系数据库的情况下， 一个一致的事务将保护定义在数据上的所有完整性约束。
隔离性(ISOLATION): 在同一个环境中可能有多个事务并发执行，而每个事务都应表现为独立执行。串行的执行一系列事务的效果应该同于并发的执行它们。这要求两件事:
在一个事务执行过程中，数据的中间的(可能不一致)状态不应该被暴露给所有的其他事务。
两个并发的事务应该不能操作同一项数据。数据库管理系统通常使用锁来实现这个特征。
持久性(DURABILITY): 一个被完成的事务的效果应该是持久的。
这些属性叫做 ACID 属性，担保一个事务是永远不会不完整，数据永远不会不一致，并发事务是独立的，一个事务的效果是持久的。关于在分布式系统什么能出错的简要的一个描述，请参见 在事务处理系统中的容错和恢复。
建造事务性应用的要点
为了引出在建造事务性应用中涉及的要点，考虑一个定单获得和定单处理应用，它的体系在 图 1 中展示：
图 1: 定单获得和定单处理应用
这个应用由两个客户构件组成，分别实现定单获得和定单处理操作。这两个操作构成了一个工作或事务单元。分别基于产品，定单，库存清单和货运信息。在这个图中，点断尖头指示的只读的数据访问，而连续尖头指示指示的是修改数据的事务性操作。下面是在这个应用中的事务性操作:
生成定单，
更新库存，
生成货运记录，并
更新定单状态。
当作为一个事务来实现这些操作时，应致力于下述要点:
应用应当与事务性操作和被操作的数据库保持联系。所以应用应该为所有事务定义一个上下文来包含上述四个操作。
因为定单获得和定单处理事务分布于两个构件之上，事务上下文应该是全局的，并通过协议的转换、被从第一个构件传播到第二个。
当事务发生期间，应用应当监控事务的状态。
为了维护事务的原子性，应用构件和/或数据库服务器、应当实现一种机制，在这种机制下对数据库的更改可以被撤消，而又不失去数据的一致性。
为了隔离在共享数据上的并发的事务，数据库服务器应该跟踪被操作的数据，并在一个事务操作期间锁住数据。
应用还应该维护数据库连接和事务之间的关联。
为了实现可靠的锁定，应用构件应向数据库通知事务的终止。
事务处理 - 体系
看到了从头开始建造一个事务性应用的要点，考虑在一个在 图 2 中展示的事务处理体系下建造相同的应用。注意，尽管有多种可能的体系，它们将在后面的章节中讨论， 图 2 中所展示的代表了本质的特征。
`
图 2: 事务处理体系
这个体系介入了一个事务管理器和每个数据库(资源)一个的资源管理器。这些构件从应用构件(定单获得和定单处理)中抽象出了特定于事务的大多数要点，并分担事务实现的职责。下面讨论这个体系的各种构件。
应用构件
应用构件:职责
建立和界定事务
传播事务上下文
通过资源管理器操作数据
应用构件是事务性资源的客户。它们是应用开发者用于实现商务事务的程序。
在事务管理器的帮助下，这些构件建立全局事务， 如果需要的话传播事务上下文，并在这些事务的范围内操作事务性资源。这些构件不负责实现保护事务的 ACID 属性。但是作为应用逻辑的一部分 ，这些构件通常做是提交还是回滚一个事务的决定。
资源管理器
资源管理器:职责
向事务服务器应征资源
参与两阶段提交和恢复协议
一个资源管理器是一个管理持久和稳定的数据存储系统的构件，并且参与同事务管理器的两段提交和恢复协议。
一个资源管理器典型的是一个稳定的存储系统上的一个驱动器或一个包装，有操作数据的接口(给应用构件), 并且为了参与由事务服务器协调的两阶段提交和恢复协议。这个构件也可以，直接的或间接的，向事务管理器注册资源，这样事务管理器就可以追踪所有参与事务的资源。这个过程叫做资源征集。为了实现两阶段提交和恢复协议，资源管理器应该实现可能被恢复所使用的附加机制。
资源管理器提供两套接口: 一套给应用构件用来连接和完成对数据的操作，另一套给事务管理器用来参与两阶段提交和恢复协议。
事务管理器
事务管理器:职责
建立和维护事务上下文
维护一个事务和特定的资源间的关联
发起并指挥两阶段提交和恢复协议
在开始两阶段提交和恢复过程之前向应用构件们做同步呼叫
事务管理器是一个事务处理环境的核心构件。它的主要职责是当应用构件要求时建立事务，允许资源征集和遣散,并指挥同资源管理器的两阶段提交或恢复协议。
一个典型的事务性应用通过向事务管理器发出一个发起事务的请求来开始一个事务。作为响应，事务管理器开始一个事务并把它同一个呼叫线程联系在一起。事务管理器也建立一个事务上下文。在事务中的所有应用构件和/或线程共享事务上下文。初始发起开始事务的请求的线程，或者如果事务管理器允许的话，任何其他线程可以通过发起提交或回滚请求来最终终止事务。
在一个事务被终止之前，在事务管理器所知道的多个数据上，多个构件和/或线程可以完成事务性操作。如果事务管理器允许的话，在事务最终完成之前，一个事务可以被挂起或被继续执行。
一旦应用发起了提交请求，事务管理器为一个提交操作准备所有资源(通过指挥一次投票表决)，并基于是否所有的资源都准备好了(就绪)提交，来发起对所有资源的一个提交或回滚请求。
事务管理是对企业应用最紧要的要求之一。在贸易、金融和电子商业领域中，多数大的企业应用依赖于递送它们的商务的事务处理功能。 鉴于当今商务对灵活性的要求，在建造、部署和维护企业级别的分布式应用中，事务处理占据的是其中最复杂的部分之一。
本文把以下内容介绍给读者:
什么是事务? 什么是 ACID?
建造一个事务应用的要点是什么? 事务管理中间件为什么很重要?
事务处理应用的典型的体系是怎样的? 体系中的各种构件的职责是什么?
事务处理系统涉及哪些概念?
事务管理领域中有哪些标准和技术?
本文不特定于任何产品，力图在描述各种要点和概念时保持普遍性。本文不打算比较各种事务处理的技术/标准，只是提供对此的一个讨论。
--------------------------------------------------------------------------------
什么是事务?
为了完成对数据的操作，企业应用经常要求并发访问在多个构件之间共享的数据。这些应用在下列条件下应该维护数据的完整性(由应用的商务规则来定义):
分布式访问一个单独的数据资源，以及
从一个单独的应用构件访问分布式资源。
在这种情况，可能要求在(分布式)资源上的一组操作被当作一个工作单元(unit)。在一个工作单元中, 操作的所有部分一起成功或失败并恢复。在下面的情况下这个问题更加复杂:
通过一组分布式的、访问多个资源的数据的构件实现一个工作单元，和/或
部分操作是被顺序执行的或在要求协调和/或同步的并行线程中。
在所有情况下, 都要求应用维护一个工作单元的成功或失败。在失败的情况下，所有资源要把数据状态返回到以前的状态 (比如说，工作单元开始前的状态)。
事务的概念和和事务管理器(或者一个事务处理服务)在一个工作单元中的维护数据完整性，这就简化了这样的企业级别分布式应用的构造。
一个事务是有下列属性的一个工作单元:
原子性(ATOMICITY): 一个事务要被完全的无二义性的做完或撤消。在任何操作出现一个错误的情况下，构成事务的所有操作的效果必须被撤消，数据应被回滚到以前的状态。
一致性(CONSISTENCY): 一个事务应该保护所有定义在数据上的不变的属性(例如完整性约束)。在完成了一个成功的事务时，数据应处于一致的状态。换句话说，一个事务应该把系统从一个一致状态转换到另一个一致状态。举个例子，在关系数据库的情况下， 一个一致的事务将保护定义在数据上的所有完整性约束。
隔离性(ISOLATION): 在同一个环境中可能有多个事务并发执行，而每个事务都应表现为独立执行。串行的执行一系列事务的效果应该同于并发的执行它们。这要求两件事:
在一个事务执行过程中，数据的中间的(可能不一致)状态不应该被暴露给所有的其他事务。
两个并发的事务应该不能操作同一项数据。数据库管理系统通常使用锁来实现这个特征。
持久性(DURABILITY): 一个被完成的事务的效果应该是持久的。
这些属性叫做 ACID 属性，担保一个事务是永远不会不完整，数据永远不会不一致，并发事务是独立的，一个事务的效果是持久的。关于在分布式系统什么能出错的简要的一个描述，请参见 在事务处理系统中的容错和恢复。
建造事务性应用的要点
为了引出在建造事务性应用中涉及的要点，考虑一个定单获得和定单处理应用，它的体系在 图 1 中展示：
图 1: 定单获得和定单处理应用
这个应用由两个客户构件组成，分别实现定单获得和定单处理操作。这两个操作构成了一个工作或事务单元。分别基于产品，定单，库存清单和货运信息。在这个图中，点断尖头指示的只读的数据访问，而连续尖头指示指示的是修改数据的事务性操作。下面是在这个应用中的事务性操作:
生成定单，
更新库存，
生成货运记录，并
更新定单状态。
当作为一个事务来实现这些操作时，应致力于下述要点:
应用应当与事务性操作和被操作的数据库保持联系。所以应用应该为所有事务定义一个上下文来包含上述四个操作。
因为定单获得和定单处理事务分布于两个构件之上，事务上下文应该是全局的，并通过协议的转换、被从第一个构件传播到第二个。
当事务发生期间，应用应当监控事务的状态。
为了维护事务的原子性，应用构件和/或数据库服务器、应当实现一种机制，在这种机制下对数据库的更改可以被撤消，而又不失去数据的一致性。
为了隔离在共享数据上的并发的事务，数据库服务器应该跟踪被操作的数据，并在一个事务操作期间锁住数据。
应用还应该维护数据库连接和事务之间的关联。
为了实现可靠的锁定，应用构件应向数据库通知事务的终止。
事务处理 - 体系
看到了从头开始建造一个事务性应用的要点，考虑在一个在 图 2 中展示的事务处理体系下建造相同的应用。注意，尽管有多种可能的体系，它们将在后面的章节中讨论， 图 2 中所展示的代表了本质的特征。
`
图 2: 事务处理体系
这个体系介入了一个事务管理器和每个数据库(资源)一个的资源管理器。这些构件从应用构件(定单获得和定单处理)中抽象出了特定于事务的大多数要点，并分担事务实现的职责。下面讨论这个体系的各种构件。
应用构件
应用构件:职责
建立和界定事务
传播事务上下文
通过资源管理器操作数据
应用构件是事务性资源的客户。它们是应用开发者用于实现商务事务的程序。
在事务管理器的帮助下，这些构件建立全局事务， 如果需要的话传播事务上下文，并在这些事务的范围内操作事务性资源。这些构件不负责实现保护事务的 ACID 属性。但是作为应用逻辑的一部分 ，这些构件通常做是提交还是回滚一个事务的决定。
资源管理器
资源管理器:职责
向事务服务器应征资源
参与两阶段提交和恢复协议
一个资源管理器是一个管理持久和稳定的数据存储系统的构件，并且参与同事务管理器的两段提交和恢复协议。
一个资源管理器典型的是一个稳定的存储系统上的一个驱动器或一个包装，有操作数据的接口(给应用构件), 并且为了参与由事务服务器协调的两阶段提交和恢复协议。这个构件也可以，直接的或间接的，向事务管理器注册资源，这样事务管理器就可以追踪所有参与事务的资源。这个过程叫做资源征集。为了实现两阶段提交和恢复协议，资源管理器应该实现可能被恢复所使用的附加机制。
资源管理器提供两套接口: 一套给应用构件用来连接和完成对数据的操作，另一套给事务管理器用来参与两阶段提交和恢复协议。
事务管理器
事务管理器:职责
建立和维护事务上下文
维护一个事务和特定的资源间的关联
发起并指挥两阶段提交和恢复协议
在开始两阶段提交和恢复过程之前向应用构件们做同步呼叫
事务管理器是一个事务处理环境的核心构件。它的主要职责是当应用构件要求时建立事务，允许资源征集和遣散,并指挥同资源管理器的两阶段提交或恢复协议。
一个典型的事务性应用通过向事务管理器发出一个发起事务的请求来开始一个事务。作为响应，事务管理器开始一个事务并把它同一个呼叫线程联系在一起。事务管理器也建立一个事务上下文。在事务中的所有应用构件和/或线程共享事务上下文。初始发起开始事务的请求的线程，或者如果事务管理器允许的话，任何其他线程可以通过发起提交或回滚请求来最终终止事务。
在一个事务被终止之前，在事务管理器所知道的多个数据上，多个构件和/或线程可以完成事务性操作。如果事务管理器允许的话，在事务最终完成之前，一个事务可以被挂起或被继续执行。
一旦应用发起了提交请求，事务管理器为一个提交操作准备所有资源(通过指挥一次投票表决)，并基于是否所有的资源都准备好了(就绪)提交，来发起对所有资源的一个提交或回滚请求。
阿牛在线 2003-12-24
- 打赏
- 举报
刚刚看到，很有兴趣，请把答案公布！！顺便放分。谢谢！！
林仪明 2003-12-23
- 打赏
- 举报
感谢大家的参与，我已经在国外的一个大学网站找到了我要答案。尽管未有人给出了令人满意的答案，本贴依然放分。
dongjiand 2003-12-21
- 打赏
- 举报
事务（Transaction）是一个操作序列．这些操作要么都做，要么都不做，是一个不可分割的工作单位，是数据库环境中的逻辑工作单位，相当于操作系统中的＂进程＂的概念．
事务的性质有
１．原子性（Atomicity）
２．一致性(Consistency)
３．隔离性(Isolation)
４．持久性(durability)
事务的性质有
１．原子性（Atomicity）
２．一致性(Consistency)
３．隔离性(Isolation)
４．持久性(durability)
online 2003-12-21
- 打赏
- 举报
事务处理协议分成两个阶段
准备阶段和提交阶段
应用程序选择控制代理，即commit agent.
commit agent可以是参与的资源管理器之一，例如com+或者其他的资源管理器
下面是执行的步骤
1。评估每一个资源管理器的条件，以com+为例
2。启动每一个管理器将会处理的方法
3。确认方法已经启动
4。应用程序检察确保所有的管理器都成功的完成了他们的功能。
5。确认没有错误
6。把条件报告给com+
7.确认可以开始提交
8。发送提交，修改所有的数据
如果任何参与的资源管理器提交失败，应用程序必须在所有的资源管理器中中止事务处理
准备阶段和提交阶段
应用程序选择控制代理，即commit agent.
commit agent可以是参与的资源管理器之一，例如com+或者其他的资源管理器
下面是执行的步骤
1。评估每一个资源管理器的条件，以com+为例
2。启动每一个管理器将会处理的方法
3。确认方法已经启动
4。应用程序检察确保所有的管理器都成功的完成了他们的功能。
5。确认没有错误
6。把条件报告给com+
7.确认可以开始提交
8。发送提交，修改所有的数据
如果任何参与的资源管理器提交失败，应用程序必须在所有的资源管理器中中止事务处理
林仪明 2003-12-20
- 打赏
- 举报
-->up于2003-12-10 14:10:00
beyondfirst 2003-12-19
- 打赏
- 举报
up
林仪明 2003-12-19
- 打赏
- 举报
-->up于2003-12-19 10:15:00
inethax 2003-12-19
- 打赏
- 举报
-->up
林仪明 2003-12-19
- 打赏
- 举报
对不起，打错了。正确的如下：
本贴为第一贴
第二贴地址如下：
http://expert.csdn.net/Expert/topic/2579/2579911.xml?temp=.9639856
本贴为第一贴
第二贴地址如下：
http://expert.csdn.net/Expert/topic/2579/2579911.xml?temp=.9639856
林仪明 2003-12-19
- 打赏
- 举报
可能我的问题没有问清楚。
我不是问如何利用.net或者sql server提供的接口来实现事务，这个我知道。我做很久的事务处理。
我想知道的是：在这背后系统是怎么做的。
分数共400分求问。
本贴为第二贴
第一贴地址如下：
http://expert.csdn.net/Expert/topic/2579/2579911.xml?temp=.9639856
我不是问如何利用.net或者sql server提供的接口来实现事务，这个我知道。我做很久的事务处理。
我想知道的是：在这背后系统是怎么做的。
分数共400分求问。
本贴为第二贴
第一贴地址如下：
http://expert.csdn.net/Expert/topic/2579/2579911.xml?temp=.9639856
林仪明 2003-12-19
- 打赏
- 举报
to:wwl1981(小刀)
是.net的事务
to:gzxin()
对象实现
是.net的事务
to:gzxin()
对象实现
gzxin 2003-12-19
- 打赏
- 举报
事务处理的题目太大了，你是希望用数据库实现还是希望用对象实现
saucer 2003-12-19
- 打赏
- 举报
this is one of the best books on Transactions:
Principles of Transaction Processing
by Philip Bernstein, Eric Newcomer
Paperback: 358 pages ; Dimensions (in inches): 0.90 x 9.24 x 7.45
Publisher: Morgan Kaufmann; 1st edition (January 15, 1997)
ISBN: 1558604154
Principles of Transaction Processing
by Philip Bernstein, Eric Newcomer
Paperback: 358 pages ; Dimensions (in inches): 0.90 x 9.24 x 7.45
Publisher: Morgan Kaufmann; 1st edition (January 15, 1997)
ISBN: 1558604154
wwl1981 2003-12-19
- 打赏
- 举报
是什么的事务，.net还是sql server
gzxin 2003-12-19
- 打赏
- 举报
对于数据库来说，一般使用两段式提交和事务日志来实现，事务日志相当于一个缓存，记录了所有操作，如果出现任何错误可以用事务日志恢复到一个可控的状态。
对象环境下的实现原理应该类似，关键是要有一个日志记录操作。
对象环境下的实现原理应该类似，关键是要有一个日志记录操作。
