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
1 package org.springframework.transaction.support; 2 3 import java.io.Flushable; 4 5 /** 6 * Interface for transaction synchronization callbacks. 7 * Supported by AbstractPlatformTransactionManager. 8 * 9 * <p>TransactionSynchronization implementations can implement the Ordered interface 10 * to influence their execution order. A synchronization that does not implement the 11 * Ordered interface is appended to the end of the synchronization chain. 12 * 13 * <p>System synchronizations performed by Spring itself use specific order values, 14 * allowing for fine-grained interaction with their execution order (if necessary). 15 * 16 * @author Juergen Hoeller 17 * @since 02.06.2003 18 * @see TransactionSynchronizationManager 19 * @see AbstractPlatformTransactionManager 20 * @see org.springframework.jdbc.datasource.DataSourceUtils#CONNECTION_SYNCHRONIZATION_ORDER 21 */ 22 public interface TransactionSynchronization extends Flushable { 23 24 /** Completion status in case of proper commit */ 25 int STATUS_COMMITTED = 0; 26 27 /** Completion status in case of proper rollback */ 28 int STATUS_ROLLED_BACK = 1; 29 30 /** Completion status in case of heuristic mixed completion or system errors */ 31 int STATUS_UNKNOWN = 2; 32 33 34 /** 35 * Suspend this synchronization. 36 * Supposed to unbind resources from TransactionSynchronizationManager if managing any. 37 * @see TransactionSynchronizationManager#unbindResource 38 */ 39 void suspend(); 40 41 /** 42 * Resume this synchronization. 43 * Supposed to rebind resources to TransactionSynchronizationManager if managing any. 44 * @see TransactionSynchronizationManager#bindResource 45 */ 46 void resume(); 47 48 /** 49 * Flush the underlying session to the datastore, if applicable: 50 * for example, a Hibernate/JPA session. 51 * @see org.springframework.transaction.TransactionStatus#flush() 52 */ 53 @Override 54 void flush(); 55 56 /** 57 * Invoked before transaction commit (before "beforeCompletion"). 58 * Can e.g. flush transactional O/R Mapping sessions to the database. 59 * <p>This callback does <i>not</i> mean that the transaction will actually be committed. 60 * A rollback decision can still occur after this method has been called. This callback 61 * is rather meant to perform work that's only relevant if a commit still has a chance 62 * to happen, such as flushing SQL statements to the database. 63 * <p>Note that exceptions will get propagated to the commit caller and cause a 64 * rollback of the transaction. 65 * @param readOnly whether the transaction is defined as read-only transaction 66 * @throws RuntimeException in case of errors; will be <b>propagated to the caller</b> 67 * (note: do not throw TransactionException subclasses here!) 68 * @see #beforeCompletion 69 */ 70 void beforeCommit(boolean readOnly); 71 72 /** 73 * Invoked before transaction commit/rollback. 74 * Can perform resource cleanup <i>before</i> transaction completion. 75 * <p>This method will be invoked after {@code beforeCommit}, even when 76 * {@code beforeCommit} threw an exception. This callback allows for 77 * closing resources before transaction completion, for any outcome. 78 * @throws RuntimeException in case of errors; will be <b>logged but not propagated</b> 79 * (note: do not throw TransactionException subclasses here!) 80 * @see #beforeCommit 81 * @see #afterCompletion 82 */ 83 void beforeCompletion(); 84 85 /** 86 * Invoked after transaction commit. Can perform further operations right 87 * <i>after</i> the main transaction has <i>successfully</i> committed. 88 * <p>Can e.g. commit further operations that are supposed to follow on a successful 89 * commit of the main transaction, like confirmation messages or emails. 90 * <p><b>NOTE:</b> The transaction will have been committed already, but the 91 * transactional resources might still be active and accessible. As a consequence, 92 * any data access code triggered at this point will still "participate" in the 93 * original transaction, allowing to perform some cleanup (with no commit following 94 * anymore!), unless it explicitly declares that it needs to run in a separate 95 * transaction. Hence: <b>Use {@code PROPAGATION_REQUIRES_NEW} for any 96 * transactional operation that is called from here.</b> 97 * @throws RuntimeException in case of errors; will be <b>propagated to the caller</b> 98 * (note: do not throw TransactionException subclasses here!) 99 */ 100 void afterCommit(); 101 102 /** 103 * Invoked after transaction commit/rollback. 104 * Can perform resource cleanup <i>after</i> transaction completion. 105 * <p><b>NOTE:</b> The transaction will have been committed or rolled back already, 106 * but the transactional resources might still be active and accessible. As a 107 * consequence, any data access code triggered at this point will still "participate" 108 * in the original transaction, allowing to perform some cleanup (with no commit 109 * following anymore!), unless it explicitly declares that it needs to run in a 110 * separate transaction. Hence: <b>Use {@code PROPAGATION_REQUIRES_NEW} 111 * for any transactional operation that is called from here.</b> 112 * @param status completion status according to the {@code STATUS_*} constants 113 * @throws RuntimeException in case of errors; will be <b>logged but not propagated</b> 114 * (note: do not throw TransactionException subclasses here!) 115 * @see #STATUS_COMMITTED 116 * @see #STATUS_ROLLED_BACK 117 * @see #STATUS_UNKNOWN 118 * @see #beforeCompletion 119 */ 120 void afterCompletion(int status); 121 122 }
从这看出点意思， spring 框架执行事务的过程中可以执行回调。而 AbstractPlatformTransactionManager.setTransactionSynchronization(int)方法就是控制是否可以执行的开关。
所以，使用 Propagation.SUPPORTS 方式 和 不使用 @Transaction 注解有两点区别：
- 前者的方法可以获取和当前事务环境一致的 Connection 或 Session，而后者肯定是新的；
- 前者可以在挂起事务、恢复事务的时侯执行回调方法，而后者做不到。
暂时先介绍到这，区别还有很多，但是希望你至少先了解这两点区别！
另外，如果没有加@Transaction,输出台会有“Closing non transactional SqlSession”提示