Spring事务传播机制和数据库隔离级别

先看下Spring的 事务传播行为类型

 

事务传播行为类型	说明
PROPAGATION_REQUIRED	如果当前没有事务，就新建一个事务，如果已经存在一个事务中，加入到这个事务中。这是 最常见的选择。
PROPAGATION_SUPPORTS	支持当前事务，如果当前没有事务，就以非事务方式执行。
PROPAGATION_MANDATORY	使用当前的事务，如果当前没有事务，就抛出异常。
PROPAGATION_REQUIRES_NEW	新建事务，如果当前存在事务，把当前事务挂起。
PROPAGATION_NOT_SUPPORTED	以非事务方式执行操作，如果当前存在事务，就把当前事务挂起。
PROPAGATION_NEVER	以非事务方式执行，如果当前存在事务，则抛出异常。
PROPAGATION_NESTED	如果当前存在事务，则在嵌套事务内执行。如果当前没有事务，则执行与 PROPAGATION_REQUIRED 类似的操作。

当使用 PROPAGATION_NESTED 时， 底层的数据源必须基于 JDBC 3.0 ，并且实现者需要支持保存点事务机制。

 

readOnly
      事务属性中的readOnly标志表示对应的事务应该被最优化为只读事务。这 是一个最优化提示 。在一些情况下，一些事务策略能够起到显著的最优化效果，例如在使用Object/Relational映射工具 （如：Hibernate或TopLink）时避免dirty checking（试图“刷新”）。

 

Timeout

       在事务属性中还有定义“timeout”值的选项，指定事务超时为几秒。在JTA中，这将被简单地传递到J2EE服务器的事务协调程序，并据此得到相应的 解释。

在xml中的设置应该是 timeout_11 表示超时为11秒。。

为什么呢。。看下面的源码可知。。

Java代码

/**
 * PropertyEditor for TransactionAttribute objects. Takes Strings of form
 *

PROPAGATION_NAME,ISOLATION_NAME,readOnly,timeout_NNNN,+Exception1,-Exception2
 *

where only propagation code is required. For example:
 *

PROPAGATION_MANDATORY,ISOLATION_DEFAULT
 *
 *

The tokens can be in any order. Propagation and isolation codes
 * must use the names of the constants in the TransactionDefinition class. Timeout values
 * are in seconds. If no timeout is specified, the transaction manager will apply a default
 * timeout specific to the particular transaction manager.
 *
 *

A "+" before an exception name substring indicates that
 * transactions should commit even if this exception is thrown;
 * a "-" that they should roll back.
 *
 * @author Rod Johnson
 * @author Juergen Hoeller
 * @since 24.04.2003
 * @see org.springframework.transaction.TransactionDefinition
 * @see org.springframework.core.Constants
 */
public class TransactionAttributeEditor extends PropertyEditorSupport {

    /**
     * Format is PROPAGATION_NAME,ISOLATION_NAME,readOnly,timeout_NNNN,+Exception1,-Exception2.
     * Null or the empty string means that the method is non transactional.
     * @see java.beans.PropertyEditor#setAsText(java.lang.String)
     */
    public void setAsText(String s) throws IllegalArgumentException {
        if (s == null || "".equals(s)) {
            setValue(null);
        }
        else {   
            // tokenize it with ","
            String[] tokens = StringUtils.commaDelimitedListToStringArray(s);
            RuleBasedTransactionAttribute attr = new RuleBasedTransactionAttribute();

            for (int i = 0; i < tokens.length; i++) {
                String token = tokens[i].trim();
                if (token.startsWith(RuleBasedTransactionAttribute.PREFIX_PROPAGATION)) {
                    attr.setPropagationBehaviorName(token);
                }
                else if (token.startsWith(RuleBasedTransactionAttribute.PREFIX_ISOLATION)) {
                    attr.setIsolationLevelName(token);
                }
                else if (token.startsWith(RuleBasedTransactionAttribute.PREFIX_TIMEOUT)) {
                    String value = token.substring(DefaultTransactionAttribute.PREFIX_TIMEOUT.length());
                    attr.setTimeout(Integer.parseInt(value));
                }
                else if (token.equals(RuleBasedTransactionAttribute.READ_ONLY_MARKER)) {
                    attr.setReadOnly(true);
                }
                else if (token.startsWith(RuleBasedTransactionAttribute.PREFIX_COMMIT_RULE)) {
                    attr.getRollbackRules().add(new NoRollbackRuleAttribute(token.substring(1)));
                }
                else if (token.startsWith(RuleBasedTransactionAttribute.PREFIX_ROLLBACK_RULE)) {
                    attr.getRollbackRules().add(new RollbackRuleAttribute(token.substring(1)));
                }
                else {
                    throw new IllegalArgumentException("Illegal transaction attribute token: [" + token + "]");
                }
            }

            setValue(attr);
        }
    }

}

/**
 * PropertyEditor for TransactionAttribute objects. Takes Strings of form
 * 
PROPAGATION_NAME,ISOLATION_NAME,readOnly,timeout_NNNN,+Exception1,-Exception2
 * 
where only propagation code is required. For example:
 * 
PROPAGATION_MANDATORY,ISOLATION_DEFAULT
 *
 * 
The tokens can be in any order. Propagation and isolation codes
 * must use the names of the constants in the TransactionDefinition class. Timeout values
 * are in seconds. If no timeout is specified, the transaction manager will apply a default
 * timeout specific to the particular transaction manager.
 *
 * 
A "+" before an exception name substring indicates that
 * transactions should commit even if this exception is thrown;
 * a "-" that they should roll back.
 *
 * @author Rod Johnson
 * @author Juergen Hoeller
 * @since 24.04.2003
 * @see org.springframework.transaction.TransactionDefinition
 * @see org.springframework.core.Constants
 */
public class TransactionAttributeEditor extends PropertyEditorSupport {

	/**
	 * Format is PROPAGATION_NAME,ISOLATION_NAME,readOnly,timeout_NNNN,+Exception1,-Exception2.
	 * Null or the empty string means that the method is non transactional.
	 * @see java.beans.PropertyEditor#setAsText(java.lang.String)
	 */
	public void setAsText(String s) throws IllegalArgumentException {
		if (s == null || "".equals(s)) {
			setValue(null);
		}
		else {	
			// tokenize it with ","
			String[] tokens = StringUtils.commaDelimitedListToStringArray(s);
			RuleBasedTransactionAttribute attr = new RuleBasedTransactionAttribute();

			for (int i = 0; i < tokens.length; i++) {
				String token = tokens[i].trim();
				if (token.startsWith(RuleBasedTransactionAttribute.PREFIX_PROPAGATION)) {
					attr.setPropagationBehaviorName(token);
				}
				else if (token.startsWith(RuleBasedTransactionAttribute.PREFIX_ISOLATION)) {
					attr.setIsolationLevelName(token);
				}
				else if (token.startsWith(RuleBasedTransactionAttribute.PREFIX_TIMEOUT)) {
					String value = token.substring(DefaultTransactionAttribute.PREFIX_TIMEOUT.length());
					attr.setTimeout(Integer.parseInt(value));
				}
				else if (token.equals(RuleBasedTransactionAttribute.READ_ONLY_MARKER)) {
					attr.setReadOnly(true);
				}
				else if (token.startsWith(RuleBasedTransactionAttribute.PREFIX_COMMIT_RULE)) {
					attr.getRollbackRules().add(new NoRollbackRuleAttribute(token.substring(1)));
				}
				else if (token.startsWith(RuleBasedTransactionAttribute.PREFIX_ROLLBACK_RULE)) {
					attr.getRollbackRules().add(new RollbackRuleAttribute(token.substring(1)));
				}
				else {
					throw new IllegalArgumentException("Illegal transaction attribute token: [" + token + "]");
				}
			}

			setValue(attr);
		}
	}

}

 

从上面可以看出  token.substring（） 这个方法把前缀timeout_给去掉了。。所以只剩下11了

从源码可看出来，PREFIX_XXXX  大都是这样写的，但前缀却是写在后面的。。觉得是不是命名有点古怪了，应该是XXXX_PREFIX，害我分析了一段时间。不过在源码上面的解释倒很清 楚：

 * PropertyEditor for TransactionAttribute objects. Takes Strings of form
 *

PROPAGATION_NAME,ISOLATION_NAME,readOnly,timeout_NNNN,+Exception1,-Exception2
 *

where only propagation code is required. For example:
 *

PROPAGATION_MANDATORY,ISOLATION_DEFAULT

文笔不好。。就给出个实例，我想一看就该明白了。

Xml代码

   
       
       
       
           
           
                PROPAGATION_REQUIRED,readOnly
                PROPAGATION_REQUIRED,timeout_11
           
       
   

    
	    
        
    	
		    
		    
			    PROPAGATION_REQUIRED,readOnly
		    	PROPAGATION_REQUIRED,timeout_11
		    
	    
	

 

总结先到这里。。等深入研究的时候再把写详细些。。。

 

 

事务隔离级别

      数据库并发操作存在的异常情况：
1. 更新丢失（Lost update）： 两个事务都同时更新一行数据但是第二个事务却中途失败退出导致对数据两个修改都失效了这是系统没有执 行任何锁操作因此并发事务并没有被隔离开来。

2. 脏读取（Dirty Reads）： 一个事务开始读取 了某行数据但是另外一个事务已经更新了此数据但没有能够及时提交。这是相当危险很可能所有操作都被回滚。

3. 不可重复读取（Non-repeatable Reads）： 一 个事务对同一行数据重复读取两次但是却得到了不同结果。例如在两次读取中途有另外一个事务对该行数据进行了修改并提交。

4. 两次更新问题（Second lost updates problem）： 无法重复读取特例，有两个并发事务同时读取同一行数据然后其中一个对它进行修改提交而另一个也进行了修改提交这就会造成 第一次写操作失效。

5. 幻读（Phantom Reads）： 也称为幻像（幻 影）。事务在操作过程中进行两次查询，第二次查询结果包含了第一次查询中未出现的数据（这里并不要求两次查询SQL语句相同）这是因为在两次查询过程中有 另外一个事务插入数据造成的。

      为了避免上面出现几种情况在标准SQL规范中定义了4个事务隔离级别，不同隔离级别对事务处理不同 。

1.未授权读取（Read Uncommitted）： 也称 未提交读。允许脏读取但不允许更新丢失，如果一个事务已经开始写数据则另外一个数据则不允许同时进行写操作但允许其他事务读此行数据。该隔离级别可以通过 “排他写锁”实现。事务隔离的最低级别，仅可保证不读取物理损坏的数据。与READ COMMITTED 隔离级相反，它允许读取已经被其它用户修改但尚未提交确定的数据。

2. 授权读取（Read Committed）： 也称提交 读。允许不可重复读取但不允许脏读取。这可以通过“瞬间共享读锁”和“排他写锁”实现，读取数据的事务允许其他事务继续访问该行数据，但是未提交写事务将 会禁止其他事务访问该行。SQL Server 默认的级别。在此隔离级下，SELECT 命令不会返回尚未提交（Committed） 的数据，也不能返回脏数据。

3. 可重复读取（Repeatable Read）： 禁止 不可重复读取和脏读取。但是有时可能出现幻影数据，这可以通过“共享读锁”和“排他写锁”实现，读取数据事务将会禁止写事务（但允许读事务），写事务则禁 止任何其他事务。在此隔离级下，用SELECT 命令读取的数据在整个命令执行过程中不会被更改。此选项会影响系统的效能，非必要情况最好不用此隔离级。

4. 串行（Serializable）： 也称可串行读。提 供严格的事务隔离，它要求事务序列化执行，事务只能一个接着一个地执行，但不能并发执行。如果仅仅通过“行级锁”是无法实现事务序列化的，必须通过其他机 制保证新插入的数据不会被刚执行查询操作事务访问到。事务隔离的最高级别，事务之间完全隔离。如果事务在可串行读隔离级别上运行，则可以保证任何并发重叠 事务均是串行的。

隔离级别     更新丢失 脏读取 重复读取 幻读
未授权读取     N            Y         Y          Y
授权读取        N            N         Y          Y
可重复 读取     N            N         N         Y
串行               N            N         N         N