`
sharajava
  • 浏览: 65688 次
  • 性别: Icon_minigender_1
  • 来自: 北京
社区版块
存档分类
最新评论

事务的理解

阅读更多

 

参考: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才可以吧?

 

 

 

 

 

 

 

  

分享到:
评论
1 楼 sharajava 2010-08-04  
之前在google上保存的一些学习笔记之一,google在中国前途还不好说,服务有时能用有时不能用的,赶紧搬家啦,回头再好好整理!里面一些图片还乱着,大家凑合看看吧!

相关推荐

Global site tag (gtag.js) - Google Analytics