/*
 * Copyright 2002-2012 the original author or authors.
 *
 * Licensed under the Apache License,Version 2.0 (the "License");
 * you may not use this file except in compliance with the License.
 * You may obtain a copy of the License at
 *
 *      http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing,software
 * distributed under the License is distributed on an "AS IS" BASIS,* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND,either express or implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
 */

package org.springframework.transaction;

/**
 * This is the central interface in Spring's transaction infrastructure.
 * Applications can use this directly,but it is not primarily meant as API:
 * Typically,applications will work with either TransactionTemplate or
 * declarative transaction demarcation through AOP.
 *
 * <p>For implementors,it is recommended to derive from the provided
 * {@link org.springframework.transaction.support.AbstractPlatformTransactionManager}
 * class,which pre-implements the defined propagation behavior and takes care
 * of transaction synchronization handling. Subclasses have to implement
 * template methods for specific states of the underlying transaction,* for example: begin,suspend,resume,commit.
 *
 * <p>The default implementations of this strategy interface are
 * { org.springframework.transaction.jta.JtaTransactionManager} and
 * { org.springframework.jdbc.datasource.DataSourceTransactionManager},* which can serve as an implementation guide for other transaction strategies.
 *
 * @author Rod Johnson
 *  Juergen Hoeller
 * @since 16.05.2003
 * @see org.springframework.transaction.support.TransactionTemplate
 *  org.springframework.transaction.interceptor.TransactionInterceptor
 *  org.springframework.transaction.interceptor.TransactionProxyfactorybean
 */
public interface PlatformTransactionManager {

    
     * Return a currently active transaction or create a new one,according to
     * the specified propagation behavior.
     * <p>Note that parameters like isolation level or timeout will only be applied
     * to new transactions,and thus be ignored when participating in active ones.
     * <p>Furthermore,not all transaction definition settings will be supported
     * by every transaction manager: A proper transaction manager implementation
     * should throw an exception when unsupported settings are encountered.
     * <p>An exception to the above rule is the read-only flag,which should be
     * ignored if no explicit read-only mode is supported. Essentially,the
     * read-only flag is just a hint for potential optimization.
     * @param definition TransactionDefinition instance (can be {@code null} for defaults),* describing propagation behavior,isolation level,timeout etc.
     * @return transaction status object representing the new or current transaction
     * @throws TransactionException in case of lookup,creation,or system errors
     *  IllegalTransactionStateException if the given transaction definition
     * cannot be executed (for example,if a currently active transaction is in
     * conflict with the specified propagation behavior)
     *  TransactionDefinition#getPropagationBehavior
     *  TransactionDefinition#getIsolationLevel
     *  TransactionDefinition#getTimeout
     *  TransactionDefinition#isReadOnly
     */
    TransactionStatus getTransaction(TransactionDefinition definition) throws TransactionException;

    
     * Commit the given transaction,with regard to its status. If the transaction
     * has been marked rollback-only programmatically,perform a rollback.
     * <p>If the transaction wasn't a new one,omit the commit for proper
     * participation in the surrounding transaction. If a prevIoUs transaction
     * has been suspended to be able to create a new one,resume the prevIoUs
     * transaction after committing the new one.
     * <p>Note that when the commit call completes,no matter if normally or
     * throwing an exception,the transaction must be fully completed and
     * cleaned up. No rollback call should be expected in such a case.
     * <p>If this method throws an exception other than a TransactionException,* then some before-commit error caused the commit attempt to fail. For
     * example,an O/R Mapping tool might have tried to flush changes to the
     * database right before commit,with the resulting DataAccessException
     * causing the transaction to fail. The original exception will be
     * propagated to the caller of this commit method in such a case.
     *  status object returned by the { getTransaction} method
     *  UnexpectedRollbackException in case of an unexpected rollback
     * that the transaction coordinator initiated
     *  HeuristicCompletionException in case of a transaction failure
     * caused by a heuristic decision on the side of the transaction coordinator
     *  TransactionSystemException in case of commit or system errors
     * (typically caused by fundamental resource failures)
     *  IllegalTransactionStateException if the given transaction
     * is already completed (that is,committed or rolled back)
     *  TransactionStatus#setRollbackOnly
     */
    void commit(TransactionStatus status) 
     * Perform a rollback of the given transaction.
     * <p>If the transaction wasn't a new one,just set it rollback-only for proper
     * participation in the surrounding transaction. If a prevIoUs transaction
     * has been suspended to be able to create a new one,resume the prevIoUs
     * transaction after rolling back the new one.
     * <p><b>Do not call rollback on a transaction if commit threw an exception.</b>
     * The transaction will already have been completed and cleaned up when commit
     * returns,even in case of a commit exception. Consequently,a rollback call
     * after commit failure will lead to an IllegalTransactionStateException.
     *  TransactionSystemException in case of rollback or system errors
     * (typically caused by fundamental resource failures)
     * void rollback(TransactionStatus status)  TransactionException;

}

 * Copyright 2002-2015 the original author or authors.
 *
 * Licensed under the Apache License,1)">import java.sql.Connection;


 * Interface that defines Spring-compliant transaction properties.
 * Based on the propagation behavior definitions analogous to EJB CMT attributes.
 *
 * <p>Note that isolation level and timeout settings will not get applied unless
 * an actual new transaction gets started. As only { #PROPAGATION_required},* { #PROPAGATION_REQUIRES_NEW} and { #PROPAGATION_NESTED} can cause
 * that,it usually doesn't make sense to specify those settings in other cases.
 * Furthermore,be aware that not all transaction managers will support those
 * advanced features and thus might throw corresponding exceptions when given
 * non-default values.
 *
 * <p>The { #isReadOnly() read-only flag} applies to any transaction context,* whether backed by an actual resource transaction or operating non-transactionally
 * at the resource level. In the latter case,the flag will only apply to managed
 * resources within the application,such as a Hibernate { Session}.
 *
 *  08.05.2003
 *  PlatformTransactionManager#getTransaction(TransactionDefinition)
 *  org.springframework.transaction.support.DefaultTransactionDefinition
 *  org.springframework.transaction.interceptor.TransactionAttribute
  TransactionDefinition {

    
     * Support a current transaction; create a new one if none exists.
     * Analogous to the EJB transaction attribute of the same name.
     * <p>This is typically the default setting of a transaction definition,* and typically defines a transaction synchronization scope.
     int PROPAGATION_required = 0;

    
     * Support a current transaction; execute non-transactionally if none exists.
     * Analogous to the EJB transaction attribute of the same name.
     * <p><b>NOTE:</b> For transaction managers with transaction synchronization,1)"> PROPAGATION_SUPPORTS} is slightly different from no transaction
     * at all,as it defines a transaction scope that synchronization might apply to.
     * As a consequence,the same resources (a JDBC { Connection},a
     * Hibernate { Session},etc) will be shared for the entire specified
     * scope. Note that the exact behavior depends on the actual synchronization
     * configuration of the transaction manager!
     * <p>In general,use { PROPAGATION_SUPPORTS} with care! In particular,do
     * not rely on { PROPAGATION_required} or { PROPAGATION_REQUIRES_NEW}
     * <i>within</i> a { PROPAGATION_SUPPORTS} scope (which may lead to
     * synchronization conflicts at runtime). If such nesting is unavoidable,make sure
     * to configure your transaction manager appropriately (typically switching to
     * "synchronization on actual transaction").
     *  org.springframework.transaction.support.AbstractPlatformTransactionManager#setTransactionSynchronization
     *  org.springframework.transaction.support.AbstractPlatformTransactionManager#SYNCHRONIZATION_ON_ACTUAL_TRANSACTION
     int PROPAGATION_SUPPORTS = 1
     * Support a current transaction; throw an exception if no current transaction
     * exists. Analogous to the EJB transaction attribute of the same name.
     * <p>Note that transaction synchronization within a { PROPAGATION_MANDATORY}
     * scope will always be driven by the surrounding transaction.
     int PROPAGATION_MANDATORY = 2
     * Create a new transaction,suspending the current transaction if one exists.
     * Analogous to the EJB transaction attribute of the same name.
     * <p><b>NOTE:</b> Actual transaction suspension will not work out-of-the-Box
     * on all transaction managers. This in particular applies to
     * { org.springframework.transaction.jta.JtaTransactionManager},* which requires the { javax.transaction.TransactionManager} to be
     * made available it to it (which is server-specific in standard Java EE).
     * <p>A { PROPAGATION_REQUIRES_NEW} scope always defines its own
     * transaction synchronizations. Existing synchronizations will be suspended
     * and resumed appropriately.
     *  org.springframework.transaction.jta.JtaTransactionManager#setTransactionManager
     int PROPAGATION_REQUIRES_NEW = 3
     * Do not support a current transaction; rather always execute non-transactionally.
     * Analogous to the EJB transaction attribute of the same name.
     * <p><b>NOTE:</b> Actual transaction suspension will not work out-of-the-Box
     * on all transaction managers. This in particular applies to
     * { javax.transaction.TransactionManager} to be
     * made available it to it (which is server-specific in standard Java EE).
     * <p>Note that transaction synchronization is <i>not</i> available within a
     * { PROPAGATION_NOT_SUPPORTED} scope. Existing synchronizations
     * will be suspended and resumed appropriately.
     * int PROPAGATION_NOT_SUPPORTED = 4
     * Do not support a current transaction; throw an exception if a current transaction
     * exists. Analogous to the EJB transaction attribute of the same name.
     * <p>Note that transaction synchronization is <i>not</i> available within a
     * { PROPAGATION_NEVER} scope.
     int PROPAGATION_NEVER = 5
     * Execute within a nested transaction if a current transaction exists,* behave like { #PROPAGATION_required} else. There is no analogous
     * feature in EJB.
     * <p><b>NOTE:</b> Actual creation of a nested transaction will only work on
     * specific transaction managers. Out of the Box,this only applies to the JDBC
     * { org.springframework.jdbc.datasource.DataSourceTransactionManager}
     * when working on a JDBC 3.0 driver. Some JTA providers might support
     * nested transactions as well.
     *  org.springframework.jdbc.datasource.DataSourceTransactionManager
     int PROPAGATION_NESTED = 6;


    
     * Use the default isolation level of the underlying datastore.
     * All other levels correspond to the JDBC isolation levels.
     *  java.sql.Connection
     int ISOLATION_DEFAULT = -1
     * Indicates that dirty reads,non-repeatable reads and phantom reads
     * can occur.
     * <p>This level allows a row changed by one transaction to be read by another
     * transaction before any changes in that row have been committed (a "dirty read").
     * If any of the changes are rolled back,the second transaction will have
     * retrieved an invalid row.
     *  java.sql.Connection#TRANSACTION_READ_UNCOMMITTED
     int ISOLATION_READ_UNCOMMITTED = Connection.TRANSACTION_READ_UNCOMMITTED;

    
     * Indicates that dirty reads are prevented; non-repeatable reads and
     * phantom reads can occur.
     * <p>This level only prohibits a transaction from reading a row
     * with uncommitted changes in it.
     *  java.sql.Connection#TRANSACTION_READ_COMMITTED
     int ISOLATION_READ_COMMITTED = Connection.TRANSACTION_READ_COMMITTED;

    
     * Indicates that dirty reads and non-repeatable reads are prevented;
     * phantom reads can occur.
     * <p>This level prohibits a transaction from reading a row with uncommitted changes
     * in it,and it also prohibits the situation where one transaction reads a row,* a second transaction alters the row,and the first transaction re-reads the row,* getting different values the second time (a "non-repeatable read").
     *  java.sql.Connection#TRANSACTION_REPEATABLE_READ
     int ISOLATION_REPEATABLE_READ = Connection.TRANSACTION_REPEATABLE_READ;

     #ISOLATION_REPEATABLE_READ}
     * and further prohibits the situation where one transaction reads all rows that
     * satisfy a { WHERE} condition,a second transaction inserts a row
     * that satisfies that { java.sql.Connection#TRANSACTION_SERIALIZABLE
     int ISOLATION_SERIALIZABLE = Connection.TRANSACTION_SERIALIZABLE;


    
     * Use the default timeout of the underlying transaction system,* or none if timeouts are not supported.
     int TIMEOUT_DEFAULT = -1
     * Return the propagation behavior.
     * <p>Must return one of the { PROPAGATION_XXX} constants
     * defined on { TransactionDefinition this interface}.
     *  the propagation behavior
     *  #PROPAGATION_required
     *  org.springframework.transaction.support.TransactionSynchronizationManager#isActualTransactionActive()
     int getPropagationBehavior();

    
     * Return the isolation level.
     * <p>Must return one of the { ISOLATION_XXX} constants
     * defined on { TransactionDefinition this interface}.
     * <p>Only makes sense in combination with { #PROPAGATION_required}
     * or { #PROPAGATION_REQUIRES_NEW}.
     * <p>Note that a transaction manager that does not support custom isolation levels
     * will throw an exception when given any other level than { #ISOLATION_DEFAULT}.
     *  the isolation level
      getIsolationLevel();

    
     * Return the transaction timeout.
     * <p>Must return a number of seconds,or { #TIMEOUT_DEFAULT}.
     * <p>Only makes sense in combination with { #PROPAGATION_REQUIRES_NEW}.
     * <p>Note that a transaction manager that does not support timeouts will throw
     * an exception when given any other timeout than { #TIMEOUT_DEFAULT}.
     *  the transaction timeout
      getTimeout();

    
     * Return whether to optimize as a read-only transaction.
     * <p>The read-only flag applies to any transaction context,whether
     * backed by an actual resource transaction
     * ({ #PROPAGATION_required}/{ #PROPAGATION_REQUIRES_NEW}) or
     * operating non-transactionally at the resource level
     * ({ #PROPAGATION_SUPPORTS}). In the latter case,the flag will
     * only apply to managed resources within the application,such as a
     * Hibernate { Session}.
     <<     * <p>This just serves as a hint for the actual transaction subsystem;
     * it will <i>not necessarily</i> cause failure of write access attempts.
     * A transaction manager which cannot interpret the read-only hint will
     * <i>not</i> throw an exception when asked for a read-only transaction.
     *  { true} if the transaction is to be optimized as read-only
     *  org.springframework.transaction.support.TransactionSynchronization#beforeCommit(boolean)
     *  org.springframework.transaction.support.TransactionSynchronizationManager#isCurrentTransactionReadOnly()
     boolean isReadOnly();

    
     * Return the name of this transaction. Can be { null}.
     * <p>This will be used as the transaction name to be shown in a
     * transaction monitor,if applicable (for example,WebLogic's).
     * <p>In case of Spring's declarative transactions,the exposed name will be
     * the { fully-qualified class name + "." + method name} (by default).
     *  the name of this transaction
     *  org.springframework.transaction.interceptor.TransactionAspectSupport
     *  org.springframework.transaction.support.TransactionSynchronizationManager#getCurrentTransactionName()
     
    String getName();

}

 * Copyright 2002-2013 the original author or authors.
 *
 * Licensed under the Apache License,1)"> java.io.Flushable;


 * Representation of the status of a transaction.
 *
 * <p>Transactional code can use this to retrieve status information,* and to programmatically request a rollback (instead of throwing
 * an exception that causes an implicit rollback).
 *
 * <p>Derives from the SavepointManager interface to provide access
 * to savepoint management facilities. Note that savepoint management
 * is only available if supported by the underlying transaction manager.
 *
 *  27.03.2003
 *  #setRollbackOnly()
 *  PlatformTransactionManager#getTransaction
 *  org.springframework.transaction.support.TransactionCallback#doInTransaction
 *  org.springframework.transaction.interceptor.TransactionInterceptor#currentTransactionStatus()
 interface TransactionStatus extends SavepointManager,Flushable {

    
     * Return whether the present transaction is new (else participating
     * in an existing transaction,or potentially not running in an
     * actual transaction in the first place).
      isNewTransaction();

    
     * Return whether this transaction internally carries a savepoint,* that is,has been created as nested transaction based on a savepoint.
     * <p>This method is mainly here for diagnostic purposes,alongside
     * { #isNewTransaction()}. For programmatic handling of custom
     * savepoints,use SavepointManager's operations.
     *  #isNewTransaction()
     *  #createSavepoint
     *  #rollbackToSavepoint(Object)
     *  #releaseSavepoint(Object)
      hasSavepoint();

    
     * Set the transaction rollback-only. This instructs the transaction manager
     * that the only possible outcome of the transaction may be a rollback,as
     * alternative to throwing an exception which would in turn trigger a rollback.
     * <p>This is mainly intended for transactions managed by
     * { org.springframework.transaction.support.TransactionTemplate} or
     * { org.springframework.transaction.interceptor.TransactionInterceptor},* where the actual commit/rollback decision is made by the container.
     *  org.springframework.transaction.support.TransactionCallback#doInTransaction
     *  org.springframework.transaction.interceptor.TransactionAttribute#rollbackOn
     void setRollbackOnly();

    
     * Return whether the transaction has been marked as rollback-only
     * (either by the application or by the transaction infrastructure).
      isRollbackOnly();

    
     * Flush the underlying session to the datastore,if applicable:
     * for example,all affected Hibernate/JPA sessions.
     
    @Override
     flush();

    
     * Return whether this transaction is completed,that is,* whether it has already been committed or rolled back.
     *  PlatformTransactionManager#commit
     *  PlatformTransactionManager#rollback
      isCompleted();

}

<bean name="transactionManager" class="org.springframework.jdbc.datasource.DataSourceTransactionManager" >
    <property name="dataSource" ref="dataSource" ></property>
</bean>

<bean name="transactionTemplate" class="org.springframework.transaction.support.TransactionTemplate" >
    <property name="transactionManager" ref="transactionManager" ></property>
</bean>

<bean name="accountDao" class="com.jichi.dao.AccountDaoImpl" >
    <property name="dataSource" ref="dataSource" ></property>
</bean>
<bean name="accountService" class="com.jichi.service.AccountServiceImpl" >
    <property name="ad" ref="accountDao" ></property>
    <property name="tt" ref="transactionTemplate" ></property>
</bean>  

class AccountServiceImpl implements AccountService {

    private AccountDao ad ;
     TransactionTemplate tt;

    @Override
    void transfer(final Integer from,final Integer to,1)">final Double money) {
        tt.execute(new TransactionCallbackWithoutResult() {
            @Override
            protected  doInTransactionWithoutResult(TransactionStatus arg0) {
                //减钱
                ad.decreaseMoney(from,money);
                加钱
                ad.increaseMoney(to,money);
            }
        });
    }
}

<bean name="transactionManager" class="org.springframework.jdbc.datasource.DataSourceTransactionManager" >
    <property name="dataSource" ref="dataSource" ></property>
</bean>

<tx:advice id="txAdvice" transaction-manager="transactionManager" >
    <tx:attributes>
        <!-- 以方法为单位,指定方法应用什么事务属性
            isolation:隔离级别
            propagation:传播行为
            read-only:是否只读
　　　　　　　timeout:过期时间
　　　　　　　 rollback-for
　　　　　　　　no-rollback-for
-->
        <tx:method name="save*" isolation="REPEATABLE_READ" propagation="required" read-only="false" />
        <tx:method name="persist*" isolation="REPEATABLE_READ" propagation="required" read-only="false" />
        <tx:method name="update*" isolation="REPEATABLE_READ" propagation="required" read-only="false" />
        <tx:method name="modify*" isolation="REPEATABLE_READ" propagation="required" read-only="false" />
        <tx:method name="delete*" isolation="REPEATABLE_READ" propagation="required" read-only="false" />
        <tx:method name="remove*" isolation="REPEATABLE_READ" propagation="required" read-only="false" />
        <tx:method name="get*" isolation="REPEATABLE_READ" propagation="required" read-only="true" />
        <tx:method name="find*" isolation="REPEATABLE_READ" propagation="required" read-only="true" />
        <tx:method name="transfer" isolation="REPEATABLE_READ" propagation="required" read-only="false" />
    </tx:attributes>
</tx:advice>

<aop:config  >
    <aop:pointcut expression="execution(* com.jichi.service.*ServiceImpl.*(..))" id="txPc"/>
    <aop:advisor advice-ref="txAdvice" pointcut-ref="txPc" />
</aop:config>

<bean name="transactionManager" class="org.springframework.jdbc.datasource.DataSourceTransactionManager" >
    <property name="dataSource" ref="dataSource" ></property>
</bean>

<tx:annotation-driven/>

@Transactional(isolation=Isolation.REPEATABLE_READ,propagation=Propagation.required,readOnly=true)
 TransactionTemplate tt;
    
    @Override
    @Transactional(isolation=Isolation.REPEATABLE_READ,1)">false)
     Double money) {
                int i = 1/0;
                 原文链接：/spring/997398.html