Spring事物伝播特性

Spring事物伝播特性
これはSpring公式の定義です.全部で7種類のソースから一部を省きました.

public interface TransactionDefinition {

    int PROPAGATION_REQUIRED = 0;

    int PROPAGATION_SUPPORTS = 1;

    int PROPAGATION_MANDATORY = 2;

    int PROPAGATION_REQUIRES_NEW = 3;

    int PROPAGATION_NOT_SUPPORTED = 4;

    int PROPAGATION_NEVER = 5;

    int PROPAGATION_NESTED = 6;

}

ROPAGATION_REQUIRED --       ，        ，       。        。 

PROPAGATION_SUPPORTS --       ，        ，         。 

PROPAGATION_MANDATORY --       ，        ，     。 

PROPAGATION_REQUIRES_NEW --     ，        ，       。 

PROPAGATION_NOT_SUPPORTED --           ，        ，        。 

PROPAGATION_NEVER --         ，        ，     。 

PROPAGATION_NESTED --         ，         。        ，    PROPAGATION_REQUIRED     

前の6つは全部分かりやすいです. PROPAAGATION_NESTEDという伝播特性は紛らわしいので、ここで特に説明します.

PROPAGATION_REQUIRES_NEW starts a new, independent "inner" transaction for the given scope. This transaction will be committed or rolled back completely independent from the outer transaction, having its own isolation scope, its own set of locks, etc. The outer transaction will get suspended at the beginning of the inner one, and resumed once the inner one has completed. Such independent inner transactions are for example used for id generation through manual sequences, where the access to the sequence table should happen in its own transactions, to keep the lock there as short as possible. The goal there is to avoid tying the sequence locks to the (potentially much longer running) outer transaction, with the sequence lock not getting released before completion of the outer transaction. PROPAGATION_NESTED on the other hand starts a "nested" transaction, which is a true subtransaction of the existing one. What will happen is that a savepoint will be taken at the start of the nested transaction. íf the nested transaction fails, we will roll back to that savepoint. The nested transaction is part of of the outer transaction, so it will only be committed at the end of of the outer transaction. Nested transactions essentially allow to try some execution subpaths as subtransactions: rolling back to the state at the beginning of the failed subpath, continuing with another subpath or with the main execution path there - all within one isolated transaction, and not losing any previous work done within the outer transaction. For example, consider parsing a very large input file consisting of account transfer blocks: The entire file should essentially be parsed within one transaction, with one single commit at the end. But if a block fails, its transfers need to be rolled back, writing a failure marker somewhere. You could either start over the entire transaction every time a block fails, remembering which blocks to skip - or you mark each block as a nested transaction, only rolling back that specific set of operations, keeping the previous work of the outer transaction. The latter is of course much more efficient, in particular when a block at the end of the file fails. 

主に緑を見ます. PROPAAGATION_NESTEPは「入れ子」のビジネスを開始します.  これは既に存在している事务の一つである.  これはsavepointを取得します.もしこのネストされた業務が失敗したら、私達はここに転びます.潜套事務は外部事務の一部です.外部事務が終わったら提出されます. 
これについては、この伝播特性は何をしているかはすでにわかっているかもしれませんが、データベースの復元点の原理を利用して、下の階にConnectionを設置します.

    ServiceA {

        /**

         *         PROPAGATION_REQUIRED

         */

        void methodA() {

            try {

                //        PROPAGATION_NESTED

                ServiceB.methodB(); //  methodB()      ，     B   SQL  

            } catch (SomeException) {

                //       ,   ServiceC.methodC();

            }

        }

    }

 
一回の文章を転載して解説するのもとても詳しいです.
http://www.iteye.com/topic/35907