1. Propagation (propagation properties of transactions)
Propagation: The key attribute determines which method the proxy should add transactional behavior to. The most important part of such properties is the propagation behavior. The following options are available: PROPAGATION_REQUIRED--support the current transaction, if there is no current transaction, create a new transaction. This is the most common choice.
PROPAGATION_SUPPORTS--Support the current transaction, if there is no current transaction, it will be executed in a non-transactional manner.
PROPAGATION_MANDATORY--supports the current transaction, if there is no current transaction, an exception is thrown.
PROPAGATION_REQUIRES_NEW--Create a new transaction, if there is a current transaction, suspend the current transaction.
PROPAGATION_NOT_SUPPORTED--Execute the operation in a non-transactional manner. If there is a current transaction, suspend the current transaction.
PROPAGATION_NEVER--Execute in a non-transactional manner, and throw an exception if a transaction currently exists.
1: PROPAGATION_REQUIRED
joins the transaction that is currently being executed and is not in another transaction, then start a new transaction.
For example, the transaction level of ServiceB.methodB is defined as PROPAGATION_REQUIRED, then when ServiceA.methodA is executed,
ServiceA.methodA has already started After the transaction is completed, ServiceB.methodB is called at this time, and ServiceB.methodB sees that it is already running
inside the transaction of ServiceA.methodA, so it will not start a new transaction. And if ServiceA. methodA finds that he is not in a transaction when he is running, he will assign himself a transaction.
In this way, if an exception occurs anywhere in ServiceA.methodA or in ServiceB.methodB, the transaction will be rolled back. Even if the transaction of ServiceB.methodB has been
committed, but ServiceA.methodA will roll back in the next fail, ServiceB.methodB will roll back
2: If PROPAGATION_SUPPORTS
is currently in a transaction, it runs as a transaction. If it is not currently in a transaction, it runs as a non-transaction
3: PROPAGATION_MANDATORY
must run in a transaction. That is, it can only be called by one parent transaction. Otherwise, he will throw an exception
4: PROPAGATION_REQUIRES_NEW
This is more convoluted. For example, if we design the transaction level of ServiceA.methodA to be PROPAGATION_REQUIRED, and the transaction level of ServiceB.methodB to be PROPAGATION_REQUIRES_NEW,
then when ServiceB.methodB is executed, the transaction where ServiceA.methodA is located will be suspended, and ServiceB.methodB will start a new one. Transaction, wait for the transaction of ServiceB.methodB to complete before
continuing to execute. The difference between him and PROPAGATION_REQUIRED is the degree of rollback of the transaction. Because ServiceB.methodB is a new transaction, there are
two different transactions. If ServiceB.methodB has been submitted, then ServiceA.methodA fails to roll back, and ServiceB.methodB will not roll back. If ServiceB.methodB fails and rolls back,
if the exception it throws is caught by ServiceA.methodA, the ServiceA.methodA transaction may still commit.
5: PROPAGATION_NOT_SUPPORTED
currently does not support transactions. For example, the transaction level of ServiceA.methodA is PROPAGATION_REQUIRED, and the transaction level of ServiceB.methodB is PROPAGATION_NOT_SUPPORTED,
then when ServiceB.methodB is executed, the transaction of ServiceA.methodA is suspended, and it runs in a non-transactional state, and then continues ServiceA .methodA's transaction.
6: PROPAGATION_NEVER
cannot be run in a transaction. Suppose the transaction level of ServiceA.methodA is PROPAGATION_REQUIRED, and the transaction level of ServiceB.methodB is PROPAGATION_NEVER,
then ServiceB.methodB will throw an exception.
7: PROPAGATION_NESTED
The key to understanding Nested is savepoint. The difference between him and PROPAGATION_REQUIRES_NEW is that PROPAGATION_REQUIRES_NEW starts a new transaction, which will be independent of his parent transaction,
while Nested’s transaction is dependent on his parent transaction, and his commit is to be submitted together with his parent transaction . In other words, if the parent transaction rolls back at the end, he will also roll back.
The advantage of the Nested transaction is that he has a savepoint.
*******************************************
ServiceA {
/**
* The transaction attribute is configured as PROPAGATION_REQUIRED
*/
void methodA() { try { //savepoint ServiceB.methodB(); //PROPAGATION_NESTED level } catch (SomeException) { // execute other services, such as ServiceC.methodC(); } }
}
********************************************
也就是说ServiceB.methodB失败回滚，那么ServiceA.methodA也会回滚到savepoint点上，ServiceA.methodA可以选择另外一个分支，比如
ServiceC.methodC，继续执行，来尝试完成自己的事务。
但是这个事务并没有在EJB标准中定义。
Spring事务的隔离级别
1. ISOLATION_DEFAULT： 这是一个PlatfromTransactionManager默认的隔离级别，使用数据库默认的事务隔离级别.
另外四个与JDBC的隔离级别相对应
2. ISOLATION_READ_UNCOMMITTED： 这是事务最低的隔离级别，它充许令外一个事务可以看到这个事务未提交的数据。
这种隔离级别会产生脏读，不可重复读和幻像读。
3. ISOLATION_READ_COMMITTED： 保证一个事务修改的数据提交后才能被另外一个事务读取。另外一个事务不能读取该事务未提交的数据
4. ISOLATION_REPEATABLE_READ： 这种事务隔离级别可以防止脏读，不可重复读。但是可能出现幻像读。
它除了保证一个事务不能读取另一个事务未提交的数据外，还保证了避免下面的情况产生(不可重复读)。
5. ISOLATION_SERIALIZABLE 这是花费最高代价但是最可靠的事务隔离级别。事务被处理为顺序执行。
除了防止脏读，不可重复读外，还避免了幻像读。
什么是脏数据，脏读，不可重复读，幻觉读？
脏读: 指当一个事务正在访问数据，并且对数据进行了修改，而这种修改还没有提交到数据库中，这时，
另外一个事务也访问这个数据，然后使用了这个数据。因为这个数据是还没有提交的数据， 那么另外一
个事务读到的这个数据是脏数据，依据脏数据所做的操作可能是不正确的。
不可重复读: 指在一个事务内，多次读同一数据。在这个事务还没有结束时，另外一个事务也访问该同一数据。
那么，在第一个事务中的两次读数据之间，由于第二个事务的修改，那么第一个事务两次读到的数据
可能是不一样的。这样就发生了在一个事务内两次读到的数据是不一样的，因此称为是不可重复读。
幻觉读: 指当事务不是独立执行时发生的一种现象，例如第一个事务对一个表中的数据进行了修改，这种修改涉及
到表中的全部数据行。同时，第二个事务也修改这个表中的数据，这种修改是向表中插入一行新数据。那么，
以后就会发生操作第一个事务的用户发现表中还有没有修改的数据行，就好象发生了幻觉一样。