使用@Transactional(SUPPORTS)和不加@Transactional 有什麼區別？

Spring 的事務傳播機制中 Propagation.SUPPORTS 級別的意義是，若是當前環境有事務，就加入到當前事務；若是沒有事務，就以非事務的方式執行。從這個說明來看，使用這個級別和不加@Transaction註解也沒什麼不同，找 API 看一下，枚舉 Propagation 的 SUPPORTS 項以下：

Support a current transaction, execute non-transactionally if none exists. Analogous to EJB transaction attribute of the same name.

Note: For transaction managers with transaction synchronization, PROPAGATION_SUPPORTS is slightly different from no transaction at all, as it defines a transaction scope that synchronization will apply for. As a consequence, the same resources (JDBC Connection, Hibernate Session, etc) will be shared for the entire specified scope. Note that this depends on the actual synchronization configuration of the transaction manager.

See Also:AbstractPlatformTransactionManager.setTransactionSynchronization(int)

除了意義的說明，文檔中還有一個 Note： 對於設置了 transaction synchronization 的事務管理器，兩種方式有微小的不一樣，即便用@Transactional(propagation = Propagation.SUPPORTS) 方式會定義一個事務做用域，等等... 可是仍是沒理解有什麼用，繼續看一下See 指向的地方

/**
 * Set when this transaction manager should activate the thread-bound
 * transaction synchronization support. Default is "always".
 * <p>Note that transaction synchronization isn't supported for
 * multiple concurrent transactions by different transaction managers.
 * Only one transaction manager is allowed to activate it at any time.
 * @see #SYNCHRONIZATION_ALWAYS
 * @see #SYNCHRONIZATION_ON_ACTUAL_TRANSACTION
 * @see #SYNCHRONIZATION_NEVER
 * @see TransactionSynchronizationManager
 * @see TransactionSynchronization
 */
public final void setTransactionSynchronization(int transactionSynchronization) {
   this.transactionSynchronization = transactionSynchronization;
}

也沒看出什麼，按照See的指示，去看 TransactionSynchronization，

package org.springframework.transaction.support;

import java.io.Flushable;

/**
 * Interface for transaction synchronization callbacks.
 * Supported by AbstractPlatformTransactionManager.
 *
 * <p>TransactionSynchronization implementations can implement the Ordered interface
 * to influence their execution order. A synchronization that does not implement the
 * Ordered interface is appended to the end of the synchronization chain.
 *
 * <p>System synchronizations performed by Spring itself use specific order values,
 * allowing for fine-grained interaction with their execution order (if necessary).
 *
 * @author Juergen Hoeller
 * @since 02.06.2003
 * @see TransactionSynchronizationManager
 * @see AbstractPlatformTransactionManager
 * @see org.springframework.jdbc.datasource.DataSourceUtils#CONNECTION_SYNCHRONIZATION_ORDER
 */
public interface TransactionSynchronization extends Flushable {

   /** Completion status in case of proper commit */
   int STATUS_COMMITTED = 0;

   /** Completion status in case of proper rollback */
   int STATUS_ROLLED_BACK = 1;

   /** Completion status in case of heuristic mixed completion or system errors */
   int STATUS_UNKNOWN = 2;


   /**
    * Suspend this synchronization.
    * Supposed to unbind resources from TransactionSynchronizationManager if managing any.
    * @see TransactionSynchronizationManager#unbindResource
    */
   void suspend();

   /**
    * Resume this synchronization.
    * Supposed to rebind resources to TransactionSynchronizationManager if managing any.
    * @see TransactionSynchronizationManager#bindResource
    */
   void resume();

   /**
    * Flush the underlying session to the datastore, if applicable:
    * for example, a Hibernate/JPA session.
    * @see org.springframework.transaction.TransactionStatus#flush()
    */
   @Override
   void flush();

   /**
    * Invoked before transaction commit (before "beforeCompletion").
    * Can e.g. flush transactional O/R Mapping sessions to the database.
    * <p>This callback does <i>not</i> mean that the transaction will actually be committed.
    * A rollback decision can still occur after this method has been called. This callback
    * is rather meant to perform work that's only relevant if a commit still has a chance
    * to happen, such as flushing SQL statements to the database.
    * <p>Note that exceptions will get propagated to the commit caller and cause a
    * rollback of the transaction.
    * @param readOnly whether the transaction is defined as read-only transaction
    * @throws RuntimeException in case of errors; will be <b>propagated to the caller</b>
    * (note: do not throw TransactionException subclasses here!)
    * @see #beforeCompletion
    */
   void beforeCommit(boolean readOnly);

   /**
    * Invoked before transaction commit/rollback.
    * Can perform resource cleanup <i>before</i> transaction completion.
    * <p>This method will be invoked after {@code beforeCommit}, even when
    * {@code beforeCommit} threw an exception. This callback allows for
    * closing resources before transaction completion, for any outcome.
    * @throws RuntimeException in case of errors; will be <b>logged but not propagated</b>
    * (note: do not throw TransactionException subclasses here!)
    * @see #beforeCommit
    * @see #afterCompletion
    */
   void beforeCompletion();

   /**
    * Invoked after transaction commit. Can perform further operations right
    * <i>after</i> the main transaction has <i>successfully</i> committed.
    * <p>Can e.g. commit further operations that are supposed to follow on a successful
    * commit of the main transaction, like confirmation messages or emails.
    * <p><b>NOTE:</b> The transaction will have been committed already, but the
    * transactional resources might still be active and accessible. As a consequence,
    * any data access code triggered at this point will still "participate" in the
    * original transaction, allowing to perform some cleanup (with no commit following
    * anymore!), unless it explicitly declares that it needs to run in a separate
    * transaction. Hence: <b>Use {@code PROPAGATION_REQUIRES_NEW} for any
    * transactional operation that is called from here.</b>
    * @throws RuntimeException in case of errors; will be <b>propagated to the caller</b>
    * (note: do not throw TransactionException subclasses here!)
    */
   void afterCommit();

   /**
    * Invoked after transaction commit/rollback.
    * Can perform resource cleanup <i>after</i> transaction completion.
    * <p><b>NOTE:</b> The transaction will have been committed or rolled back already,
    * but the transactional resources might still be active and accessible. As a
    * consequence, any data access code triggered at this point will still "participate"
    * in the original transaction, allowing to perform some cleanup (with no commit
    * following anymore!), unless it explicitly declares that it needs to run in a
    * separate transaction. Hence: <b>Use {@code PROPAGATION_REQUIRES_NEW}
    * for any transactional operation that is called from here.</b>
    * @param status completion status according to the {@code STATUS_*} constants
    * @throws RuntimeException in case of errors; will be <b>logged but not propagated</b>
    * (note: do not throw TransactionException subclasses here!)
    * @see #STATUS_COMMITTED
    * @see #STATUS_ROLLED_BACK
    * @see #STATUS_UNKNOWN
    * @see #beforeCompletion
    */
   void afterCompletion(int status);

}

從這看出點意思， spring 框架執行事務的過程當中能夠執行回調。而 AbstractPlatformTransactionManager.setTransactionSynchronization(int)方法就是控制是否能夠執行的開關。 因此，使用 Propagation.SUPPORTS 方式 和 不使用 @Transaction 註解有兩點區別：

1. 前者的方法能夠獲取和當前事務環境一致的 Connection 或 Session，然後者確定是新的；
2. 前者能夠在掛起事務、恢復事務的時侯執行回調方法，然後者作不到。

ps：並無看全整個流程的源碼，再看時候進行補充！