使⽤@Transactional(propagation=Propagation.SUPP。。。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) {
}
也没看出什么,按照See的指⽰,去看 TransactionSynchronization
1 package ansaction.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*/
22public interface TransactionSynchronization extends Flushable {
23
24/** Completion status in case of proper commit */
25int STATUS_COMMITTED = 0;
26
27/** Completion status in case of proper rollback */
28int STATUS_ROLLED_BACK = 1;
29
30/** Completion status in case of heuristic mixed completion or system errors */
31int 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*/
39void suspend();
40
41/**
42 * Resume this synchronization.
43 * Supposed to rebind resources to TransactionSynchronizationManager if managing any.
44 * @see TransactionSynchronizationManager#bindResource
45*/
46void resume();
47
48/**
49 * Flush the underlying session to the datastore, if applicable:
50 * for example, a Hibernate/JPA session.
51 * @see ansaction.TransactionStatus#flush()
52*/
53 @Override
54void flush();
55
56/**
57 * Invoked before transaction commit (before "beforeCompletion").
58 * 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*/
70void 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*/
83void 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> commit further operations that are supposed to follow on a successful
89 * commit of the main transaction, like confirmation messages or emails.
springframework事务
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*/
100void 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*/
120void afterCompletion(int status);
121
122 }
从这看出点意思, spring 框架执⾏事务的过程中可以执⾏回调。⽽
AbstractPlatformTransactionManager.setTransactionSynchronization(int)⽅法就是控制是否可以执⾏的开关。所以,使⽤ Propagation.SUPPORTS ⽅式和不使⽤ @Transaction 注解有两点区别:
1. 前者的⽅法可以获取和当前事务环境⼀致的 Connection 或 Session,⽽后者肯定是新的;
2. 前者可以在挂起事务、恢复事务的时侯执⾏回调⽅法,⽽后者做不到。
暂时先介绍到这,区别还有很多,但是希望你⾄少先了解这两点区别!
另外,如果没有加@Transaction,输出台会有“Closing non transactional SqlSession”提⽰
版权声明:本站内容均来自互联网,仅供演示用,请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198,我们将在24小时内删除。
发表评论