参考:http://www.subbu.org/articles/transactions/NutsAndBoltsOfTP.html
属性(Properties)
ACID(Atomicity, Consistency, Isolation, Durability)
应用开发人员应该关心并可以控制的A和I,C和D由事务资源负责(如数据库)。
别的根本是在事务性资源中设置并控制的。大多数数据库系统都以READ
COMMITTED为默认的事务隔离级别,如Oracle。当Oracle的事务隔离级别是READ COMMITTED时,我们不论如何不可能让我们的程序运行出READ
UNCOMMITTED的效果来的。也就是说在程序中,我们只能根据底层事务资源事务隔离级别,在其级别的上层做点文章。比如,在oracle默认的隔离级别下,我们的程序只能做到READ
COMMITTED,REPEATABLE READ和SERIALIZABLE。(纯属个人理解,不一定对)
事务隔离级别
SERIALIZABLE: This is the most
restrictive level. Transactions should appear to run as if they were executed
one by one after each other. This means that two transactions are not allowed
to read or write a piece of data that the other one has changed or will change
during the entire life span of the transactions. This is the isolation level
that gives you the best protection against interference by concurrent changes.
It is also the level that is the most expensive to maintain in terms of
resource usage.
REPEATABLE READ: Now we have to
guarantee that we will not see any updates made by other transactions to any
data that we have accessed within a transaction. If we read the data again, it
should always be unchanged. There could, however, be additional data that has
been added by another transaction. This is called a phantom read.
READ COMMITTED: Here we relax
the isolation a bit further. We will not see any changes made by other
transactions while they are active. Once they finish and commit their work we
will be able to see the changes. This means that we can't guarantee repeatable
reads; instead we get unrepeatable reads — data we have already read can change
while our transaction is running and a later read or update could operate on
modified data.
READ UNCOMMITTED: All bets are
off. There is practically no isolation. Any transaction can see changes made by
other transactions even before they are committed. These types of reads of
uncommitted data are called dirty reads.
You are, however, not able to update data that has been modified by another
transaction until the other transaction has completed.
NONE: This level indicates that there is no transaction support. This level
is not provided by most databases.
不可重复读(non-repeatable
reads)
一个事务重新读取前面读取过的数据,
发现该数据已经被另一个已提交的事务修改过。
幻读(phantom
read)
一个事务重新执行一个查询,返回一套符合查询条件的行,
发现这些行因为其他最近提交的事务而发生了改变。
隔离级别
|
脏读(Dirty
Read)
|
不可重复读(NonRepeatable
Read)
|
幻读(Phantom
Read)
|
读未提交(Read uncommitted)
|
可能
|
可能
|
可能
|
读已提交(Read committed)
|
不可能
|
可能
|
可能
|
可重复读(Repeatable read)
|
不可能
|
不可能
|
可能
|
可串行化(Serializable )
|
不可能
|
不可能
|
不可能
|
好的定义都应该是完备的,从“
0 ”开始数:
NONE(0):不隔离,随便读,随便写;
READ UNCOMMITTED(1):随便读,不随便写(等人家提交了才能写);
READ COMMITTED(2):不随便读,不随便写(读、写都得是提交后的);
REPEATABLE READ(3):完全“看”不到别人产生的影响(事务内),写与2级相同;
SERIALIZABLE(4):永远只有一个事务在工作。
|
划分(Demarcation)
编程式的事务划分:自己的程序里控制commit和rollback。常见的场景是在J2EE环境中调用JTA(Java
Transaction API)。
声明式的事务划分:EJB规范中最优秀的部分,另外还有其它可选方案,如Spring(J2EE
without EJB)。
EJB规则中定义了CMT事务划分:
REQUIRED: This means that the
method must participate in a transaction. A new transaction will be started if
one is not already active.
REQUIRES NEW: A new transaction
will always be started for this method. If there is an active transaction for
the calling component, then that transaction is suspended until this method has
completed.
NOT SUPPORTED: The method will
not take part in any transactions. If there is one active in the calling
component, then it is suspended while this method is processing. The suspended
transaction is resumed once this method has completed.
SUPPORTS: There is no
requirement that this method should be executed in a transaction. If one is
already started, then this method will take part in that transaction.
MANDATORY: The calling component
must already have an active transaction that this method will take part in.
NEVER: This method is not
participating in a transaction and it is also required that there is not an
active transaction for the calling component.
Spring在EJB规则的基础上增加了NESTED 参考:http://sharajava.iteye.com/blog/78270
以上内容主要涉及在本地事务(事务中只涉及一个事务性资源的事务)范围内,以下进入分布式事务。
X/Open 分布事务处理模型
Distributed Transaction Processing Model
X/Open模型中的组件:
1.
Application Programs
2.
Resource Managers
3.
Transaction Managers
4.
Communication Resource Manager 协调多个事务性资源
(补图)
接口规范:
1.
TX接口 Application Programs调用Transaction
Managers,由Transaction Managers实现。
2.
XA接口
xa_*
Transaction Managers调用Resource Managers,由Resource Managers实现。
ax_*
Resource Managers调用Transaction Managers,由Transaction Managers实现。
其它接口略,目前没有接触过。
OTS
Object
Transaction Service (OTS) is a distributed transaction processing service
specified by the Object Management Group (OMG). This
specification extends the CORBA model and
defines a set of interfaces to perform transaction processing across multiple
CORBA objects.
The OTS model is based on the X/Open DTP model with the
following enhancements:
·
The OTS model replaces the
functional XA and TX interfaces with CORBA IDL interfaces.
·
The various objects in this model
communicate via CORBA method calls over IIOP.
JTA/JTS
JTS specifies the implementation
of a Java transaction manager. This transaction manager supports the JTA, using
which application servers can be built to support transactional Java
applications. Internally the JTS implements the Java mapping of the OMG OTS 1.1 specifications. The Java mapping is
specified in two packages: org.omg.CosTransactions and org.omg.CosTSPortability. Although
the JTS is a Java implementation of the OMG OTS 1.1 specification, the JTA
retains the simplicity of the XA and TX functional interfaces of the X/Open DTP
model.
(补图)
下面是JTA/JTS规范中都强调的图,没事好好琢磨琢磨。
http://picasaweb.google.com/sharajava/Tech/photo#5070948952183247154
图中那些彩色的线就是JTA,也就是Java企业应用场景下,所有事务交互的抽象及接口规范,也就是以下5个组件(比X/Open模型多一个应用服务器,因为这是典型的J2EE环境)之间的相互关系。
JTS与JTA的关系从JTS的定义就可以看出来:
JTS
specifies the implementation of a
transaction manager which supports the JTA specification at the high-level
and implements the Java mapping of the
OMG Object Transaction Service (OTS) 1.1 Specification at the low-level.
JTS定义了JTA中Transaction
Manager的实现方法,也就是应该如何实现JTA中关于Transaction Manager部分的规范。除此之外,JTS还定义了OTS到Java的映射,也就是如何用Java实现OTS。
A transaction
manager-sharajava 07-6-7 下午8:34
provides the services and management functions required to support
transaction demarcation, transactional resource management, synchronization,
and transaction context propagation.
An application
server (or TP monitor)-sharajava 07-6-7 下午8:27
provides the infrastructure required to support the application run-time
environment which includes transaction state management. An example of such an
application server is an EJB server.
A resource
manager (through a resource adapter1) provides the application access to
resources. The resource manager participates in distributed transactions by
implementing a transaction resource interface used by the transaction manager
to communicate transaction association, transaction completion and recovery
work. An example of such a resource manager is a relational database server.
A component-based transactional application that is developed to operate in a modern application
server environment relies on the application server to provide transaction
management support through declarative transaction attribute settings. An
example of this type of applications is an application developed using the
industry standard Enterprise JavaBeans (EJB) component architecture. In addition, some other stand-alone Java
client programs may wish to control their transaction boundaries using a
high-level interface provided by the application server or the transaction
manager.
A communication resource manager (CRM)
supports transaction context propagation and access to the transaction service
for incoming and outgoing requests. The JTA document does not specify
requirements pertained to communication. Refer to the JTS Specification for
more details on interoperability between Transaction Managers.
这篇文章格式搞乱掉了,还需要重新好好整理。
补充一些新想到的问题:
- Spring事务抽象的PlatformTransactionManager与DataSource是什么关系?
- 用JDBC的数据源可以使用JTA吗?
- 需要数据源支持JTS才可以吧?
分享到:
相关推荐
以下是对`jdbc+spring+mysql事务理解和分析`的详细说明: 1. **原子性(Atomicity)**:这是事务的基本特性,表示事务中的所有操作要么全部成功,要么全部回滚。如果在事务执行过程中发生错误,数据库会撤销所有已...
Java Transaction Service (JTS) 是 J2EE 平台的核心组件,主要负责处理分布式环境中的事务管理。JTS 结合了 Java Transaction API (JTA),为开发者提供了在复杂分布式应用程序中实现事务处理的能力,确保了数据的...
MySQL 事务理解及相关操作 MySQL 是一款广泛应用的关系型数据库管理系统,它支持多种表引擎,其中两种最常见的是 MyISAM 和 InnoDB。MyISAM 是 MySQL 5.5 版本之前的默认表引擎,它不支持事务处理和外键,但提供表...
### 深入理解分布式事务 #### 一、分布式事务定义及重要性 分布式事务是指在分布式系统中,为了确保跨多个节点上的操作能够正确地完成或者全部回滚,所采取的一种事务处理机制。在这样的场景下,事务的参与者、...
1. 事务理解: - 原子性(Atomicity):事务中的所有操作要么全部完成,要么全部不完成,不会留下部分结果。 - 一致性(Consistency):事务完成后,数据库应处于一致状态,即事务前后,数据的完整性得到维护。 -...
Spring 框架是Java开发中...理解并熟练掌握Spring事务管理,对于提升应用程序的稳定性和可靠性至关重要。在实际开发中,结合声明式事务管理、事务传播行为、隔离级别和回滚规则,可以有效地确保数据的完整性和一致性。
本文来自于csdn,本文主要从分布式的原因,事务特性,和解决方案中深入理解了分布式事务,希望对您的学习有所帮助。 分布式事务就是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的...
### 深入理解Spring的事务管理机制 #### 一、事务的基本原理 Spring框架的事务管理机制是在Java开发环境中非常重要的一个组成部分,它能够帮助开发者简化事务处理的复杂度,提高应用程序的一致性和可靠性。Spring...
深入理解Mysql事务隔离级别与锁机制 Mysql事务隔离级别与锁机制是数据库系统中非常重要的概念,它们都是为了解决多事务并发问题而设计的。下面我们将深入讲解这些机制,让大家彻底理解数据库内部的执行原理。 事务...
在Spring框架中,事务管理是核心功能之一,它确保了数据操作的一致性和完整性。本教程将深入探讨如何在Spring中实现自定义事务管理器...这将加深你对Spring事务管理的理解,帮助你在实际项目中更加熟练地运用这些技术。
在理解 MyBatis 的事务管理之前,首先需要明确事务的基本概念。事务是数据库操作的基本单元,确保数据的一致性和完整性。通常,事务包含四个特性,即原子性(Atomicity)、一致性(Consistency)、隔离性(Isolation...
Spring 编程式事务与声明式事务详解 本文将详细解释 Spring...本文通过详细分析 Spring 的编程式事务管理及声明式事务管理,帮助读者理解事务管理的重要性和实现方式。读者可以根据自己的需求选择合适的事务管理方式。
《若依框架分布式事务配置与...通过阅读《分布式事务 _ RuoYi.pdf》、《后台手册 _ RuoYi.pdf》等文档,以及实践《环境部署 _ RuoYi.pdf》中的步骤,开发者能够更深入地理解若依框架的分布式事务管理和项目启动过程。
本篇文章将详细解释Spring事务管理的流程,以及如何通过时序图来理解这一过程。 首先,我们来看Spring事务的流程。当一个事务开始时,通常会经历以下步骤: 1. **开启事务**:在业务方法执行前,Spring会检查是否...
### Spring Boot 与 Spring 事务详解 #### 一、引言 在现代企业级应用程序开发中,事务管理是一项至关重要的技术。...希望本文能帮助您更好地理解和运用 Spring 与 Spring Boot 中的事务管理功能。
### Spring中事务的传播属性详解 #### 一、引言 ...正确理解和运用这些传播行为对于实现健壮、高效的事务管理至关重要。在实际开发中,应根据业务需求合理选择合适的传播行为,确保系统的稳定性和可靠性。
Java 事务管理和事务分类主要涉及如何确保在多步骤操作中数据的一致性和完整性。事务是数据库操作的基本单元,遵循ACID原则,即原子性...理解这些概念和机制对于构建健壮的、能够处理复杂业务逻辑的Java应用至关重要。
在Spring框架中,事务管理是核心特性之一,它允许开发者以声明式或编程式的方式处理应用中的事务。Spring事务管理的目的是确保数据的一致性和完整性,...这样可以帮助你更好地理解Spring事务管理的工作原理和实际应用。
Java分布式事务是大型分布式系统中不可或缺的一个重要组成部分,它确保在多个网络节点间的数据操作能够保持一致性和完整性。...通过学习和理解这些示例,开发者可以更好地掌握Java分布式事务的原理和实践。