如何让jms事务与数据库事务处于同一事务中

事务是这样一种机制，它确保多个SQL语句被当作单个工作单

元来处理。事务具有以下的作用：

* 一致性：同时进行的查询和更新彼此不会发生冲突，其他

用户不会看到发生了变化但尚未提交的数据。

* 可恢复性：一旦系统故障，数据库会自动地完全恢复未完

成的事务。

二 事务与一致性

事务是完整性的单位，一个事务的执行是把数据库从一个一

致的状态转换成另一个一致的状态。因此，如果事务孤立执行时

是正确的，但如果多个事务并发交错地执行，就可能相互干扰，

造成数据库状态的不一致。在多用户环境中，数据库必须避免同

时进行的查询和更新发生冲突。这一点是很重要的，如果正在被

处理的数据能够在该处理正在运行时被另一用户的修改所改变，

那么该处理结果是不明确的。

不加控制的并发存取会产生以下几种错误：

1 丢失修改（lost updates）

当多个事务并发修改一个数据时，不加控制会得出错误的结

果，一个修改会覆盖掉另一个修改。

2 读的不可重复性

当多个事务按某种时间顺序存取若干数据时，如果对并发存

取不加控制，也会产生错误。

3 脏读（DIRDY DATA），读的不一致性

4 光标带来的当前值的混乱

事务在执行过程中它在某个表上的当前查找位置是由光标表

示的。光标指向当前正处理的记录。当处理完该条记录后，则指

向下一条记录。在多个事务并发执行时，某一事务的修改可能产

生负作用，使与这些光标有关的事务出错。

5 未释放修改造成连锁退出

一个事务在进行修改 *** 作的过程中可能会发生故障，这时需

要将已做的修改回退（Rollback）。如果在已进行过或已发现错

误尚未复原之前允许其它事务读已做过修改（脏读），则会导致

连锁退出。

6 一事务在对一表更新时，另外的事务却修改或删除此表的

定义。

数据库会为每个事务自动地设置适当级别的锁定。对于前面

讲述的问题：脏读、未释放修改造成的连锁退出、一事务在对一

表更新时另外的事务却修改或删除此表的定义，数据库都会自动

解决。而另外的三个问题则需要在编程过程中人为地定义事务或

加锁来解决。

三 事务和恢复

数据库本身肩负着管理事务的责任。事务是最小的逻辑工作

单元，在这个工作单元中，对数据库的所有更新工作，要么必须

全部成功，要么必须全部失败（回退）。只要应用程序指定了某

段程序为一个事务并做了相应的处理（提交或回退），数据库系

统会自动维护事务本身的特性。

四 ORACLE数据库的事务定义

ORACLE事务从COMMIT、ROLLBACK、连接到数据库或开始第一

条可执行的SQL语句时开始，到一条COMMIT、ROLLBACK语句或退出

数据库时结束。如果在一个事务中包含DDL语句，则在DDL语句的

前后都会隐含地执行COMMIT语句，从而开始或结束一个事务。

如果一个事务由于某些故障或者由于用户改变主意而必须在

提交前取消它，则数据库被恢复到这些语句和过程执行之前的状

态。

利用ROLLBACK语句可以在COMMIT命令前随时撤消或回退一个

事务。可以回退整个事务，也可以会退部分事务，但是不能回退

一个已经被提交的事务。回退部分事务的ROLLBACK命令为：

ROLLBACK to savepoint 存储点名

存储点是用户放入事务中的标记，用来表示一个可被回退的

位置。存储点通过在事务中放入一个SAVEPOINT命令而被插入。该

命令的语法是：

SAVEPOINT 存储点名

如果在ROLLBACK语句中没有给出存储点名，则整个事务被回

退。

五 SYBASE数据库的事务定义

SYBASE通过使用BEGIN TRANsaction和COMMIT TRANsaction命令指

示SQL将任意数目的语句作为一个单元来处理。ROLLBACK TRANsaction

命令则允许用户恢复到事务的开始，或恢复到事务内部已经被用SAVE

TRANsaction命令定义的存储点上。

BEGIN TRANsaction和COMMIT TRANsaction能够包含任意数目的SQL

语句和存储过程，方法很简单：

BEGIN TRANsaction [事务名称]

COMMIT TRANsaction

如果一个事务由于某些故障或者由于用户改变主意而必须在提交

前取消它，则数据库被恢复到这些语句和过程执行之前的状态。

利用ROLLBACK TRANsaction命令可以在COMMIT TRANsaction命令

前随时回退一个事务。可以回退整个事务，也可以回退部分事务，但

是不能回退一个已经被提交的事务。ROLLBACK TRANsaction命令为：

ROLLBACK TRANsaction [事务名|存储点名]

存储点名是用户放入事务中的标记，用来表示一个可以被回退的

位置。存储点名通过在事务中放入一个SAVE TRANsaction命令而被插

入。该命令的句法是：

SAVE TRANsaction 存储点名

如果在ROLLBACK TRANsaction中没有给出存储点名或事务名，则

事务被回退到批处理中的第一个BEGIN TRANsaction语句处。

JMS

开放分类： 程序、计算机、网络用语

JMS（Java Messaging Service）是Java平台上有关面向消息中间件的技术规范，翻译为Java消息服务。JMS支持点对点和发布/订阅两种消息模型。

JMS基本概念

1.JMS(Java Message Service)是访问企业消息系统的标准API,它便于消息系

统中的Java应用程序进行消息交换,并且通过提供标准的产生、发送、接收消息的接口简化企业应用的开发。

2. JMS基本功能

JMS是用于和面向消息的中间件相互通信的应用程序接口。它既支持点对点(point-to-point)的域，又支持发布/订阅(publish/subscribe)类型的域，并且提供对下列类型的支持：经认可的消息传递,事务型消息的传递，一致性消息和具有持久性的订阅者支持。JMS还提供了另一种方式来对您的应用与旧的后台系统相集成。

3. WebLogic JMS Server介绍

WebLogic Server8.1符合JAVA规范,并通过Sun Microsystems J2EE 1.3认

证.作为WebLogic的一部分,当然WebLogic JMS Server也完全遵从JMS规范,还支持集群,并可以应用于实际企业系统.下图是WebLogic JMS Server体系结构.图中可以看到WebLogic JMS Server主要组件有: WebLogic JMS servers(用于消息通信),Java客户端,JNDI(用于域名查找), 后备存储(用于持久消息存储,基于文件或者JDBC数据库).

WebLogic JMS特性

1. 消息通信模型

JMS 支持两种消息通信模型：点到点（point-to-point）（PTP）模型和发布/订阅（Pub/Sub）模型。除了下列不同之外，这两种消息通信模型非常地相似：

PTP 模型规定了一个消息只能有一个接收者Pub/Sub 模型允许一个消息可以有多个接收者。

2. 消息组成

消息传递系统的中心就是消息。

一条 Message 分为三个组成部分：

· 头（header）是个标准字段集，客户机和供应商都用它来标识和路由消息。

· 属性（property）支持把可选头字段添加到消息。如果您的应用程序需要不使用标准头字段对消息编目和分类，您就可以添加一个属性到消息以实现这个编目和分类。提供 set<Type>Property(...) 和 get<Type>Property(...) 方法以设置和获取各种 Java 类型的属性，包括 Object。JMS 定义了一个供应商选择提供的标准属性集。

· 消息的主体（body）包含要发送给接收应用程序的内容。每个消息接口特定于它所支持的内容类型。

JMS 为不同类型的内容提供了它们各自的消息类型，但是所有消息都派生自 Message 接口。

· StreamMessage：包含 Java 基本数值流，用标准流 *** 作来顺序的填充和读取。

· MapMessage：包含一组名/值对；名称为 string 类型，而值为 Java 的基本类型。

· TextMessage：包含一个 String。

· ObjectMessage：包含一个 Serializable Java 对象；能使用 JDK 的集合类。

· BytesMessage：包含未解释字节流: 编码主体以匹配现存的消息格式。

· XMLMessage: 包含XML内容。扩展TextMessage,XMLMessage 类型的使用，使得消息过滤非常便利。

3. 消息确认模式

非事务性会话中，应用程序创建的会话有5 种确认模式,而在事务性会话中，确认模式被忽略。

五种确认模式说明:

· AUTO_ACKNOWLEDGE：自动确认模式。一旦接收方应用程序的方法调用从处理消息处返回，会话对象就会确认消息的接收。

· CLIENT_ACKNOWLEDGE：客户端确认模式。会话对象依赖于应用程序对被接收的消息调用一个acknowledge()方法。一旦这个方法被调用，会话会确认最后一次确认之后所有接收到的消息。这种模式允许应用程序以一个调用来接收，处理并确认一批消息。注意：在管理控制台中，如果连接工厂的Acknowledge Policy（确认方针）属性被设置为"Previous"（提前），但是你希望为一个给定的会话确认所有接收到的消息，那么就用最后一条消息来调用acknowledge()方法。

· DUPS_OK_ACKNOWLEDGE：允许副本的确认模式。一旦接收方应用程序的方法调用从处理消息处返回，会话对象就会确认消息的接收；而且允许重复确认。在需要考虑资源使用时，这种模式非常有效。注意：如果你的应用程序无法处理重复的消息的话，你应该避免使用这种模式。如果发送消息的初始化尝试失败，那么重复的消息可以被重新发送。

· NO_ACKNOWLEDGE：不确认模式。不确认收到的消息是需要的。消息发送给一个NO_ACKNOWLEDGE 会话后，它们会被WebLogic 服务器立即删除。在这种模式下，将无法重新获得已接收的消息，而且可能导致下面的结果：1. 消息可能丢失；和（或者）另一种情况：2. 如果发送消息的初始化尝试失败，会出现重复消息被发送的情况。

· MULTICAST_NO_ACKNOWLEDGE：IP组播下的不确认模式，同样无需确认。发送给一个MULTICAST_NO_ACKNOWLEDGE会话的消息， 会共享之前所述的NO_ACKNOWLEDGE 确认模式一样的特征。这种模式支持希望通过IP 组播方式进行消息通信的应用程序，而且无需依赖会话确认提供的服务质量。注意：如果你的应用程序无法处理消息的丢失或者重复，那么你应该避免使用这种模式。如果发送消息的初始化尝试失败的话，重复的消息可能会被再次发送。

注：在上表的5 种确认模式中，AUTO_ACKNOWLEDGE ，DUPS_OK_ACKNOWLEDGE 和

CLIENT_ACKNOWLEDGE 是JMS 规范定义的，NO_ACKNOWLEDGE 和MULTICAST_NO_ACKNOWLEDGE是WebLogic JMS 提供的