参考: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才可以吧?
分享到:
相关推荐
JTS事务理解1
jdbc+spring+mysql事务理解和分析
自己学习MySQL时候做的思维导图。
深入理解分布式事务
订单与选课需求分析 理解 理解订单与选课需求分析 "理解订单支付流程理解订单支付数据模型理解自动选课需求"分布式事务解决方案 理解 重点 理解基于消息队列的分布式事务解决方案 "理解什么是分布式事务理解CAP理论...
本文来自于csdn,本文主要从分布式的原因,事务特性,和解决方案中深入理解了分布式事务,希望对您的学习有所帮助。 分布式事务就是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的...
spring 事务管理的理解
不支持事务 不支持外键 提供 表锁 存储数据时,会将数据存储在三个文件中:一个文件存数据,一个文件存结构,一个文件存索引 innodb: 支持事务 支持外键 提供 行锁 存储数据时,会将数据存储在两个文件中:一个文件...
06-VIP-深入理解Mysql事务隔离级别与锁机制.pdf
MyBatis 事务管理解析:颠覆你心中对事务的理解!
Seata原理和设计定义一个分布式事务我们可以把一个分布式事务理解成一个包含了若干分支事务的全局事务,全局事务的职责是协调其下管辖的分支事务达成一致,要么一起成
这篇文章将介绍什么是分布式事务,分布式事务解决什么问题,对 分布式事务实现的难点,解决思路,不同场景下方案的选择,通过图解的方式进行梳理、总结和比较。相信耐心看完这篇文章,谈到分布式事务,不再只是有“2...
Spring框架的声明式事务管理是Java开发中的核心特性,它为高效且可靠的数据操作提供了强大支持。...深入理解Spring声明式事务的工作原理,不仅能帮助开发者更高效地使用Spring框架,也是提升Java企业级开发能力的关键。
数据库事务:对数据库事务的讲解,事务的概念 理解事务的特性、分类
1.说到数据库事务,⼈们脑海⾥⾃然不⾃然的就会浮现出事务的四⼤特性、四⼤隔离级别、七⼤传播特性。 四⼤还好说,问题是七⼤传播特性是哪⼉来的?是Spring在当前线程内,处理多个数据库操作⽅法事务时所做的⼀种...
【免费】深入描述spring的事务处理机制,很不错的资源。
事务的基本概念-ACID 2 事务(Transaction)是访问并可能更新数据库中各种数据项的一个程序执行单元 (unit)。在关系数据库中,一个事务由一组SQL语句组成。事务应该具有4个属性: 原子性、一致性、隔离性、持久性。这...
[数据库事务与锁]详解七 深入理解乐观锁与悲观锁
一文理解分布式事务的解决方案.docx
深入理解Mysql事务隔离级别与锁机制.pdf