Can you answer the questions that cannot be answered with a monthly salary of 10k-20k?

Today, a friend threw a “ Simple ” Transaction code for , Tasteless at first sight , Look at the surprise again .

I also asked some friends around me, and none of them answered correctly , Try it, too ？

@Service
public class TestService {
    

    @Autowired
    private TestMapper testMapper;

    @Autowired
    private TestServiceTwo testServiceTwo;

    @Transactional(rollbackFor = Exception.class)
    public String funOne(){
    
        //  This is a simple insert sentence 
        testMapper.insert("a");
        try {
    
            testServiceTwo.funTwo();
        }catch (Exception e){
    
            System.out.println(" Abnormal ~~~");
        }
        return "da";
    }
}

@Service
public class TestServiceTwo {
    

    @Transactional(rollbackFor = Exception.class)
    public void funTwo(){
    
        throw new RuntimeException("DASDASDA");
    }
}

ask ： Finally, several pieces of data were inserted into the database ？（ Put the answers in the text ）

Here are a few conclusions. Let's prove them one by one , After reading it, you will understand .

One 、spring Annotation based transactions are agent-based , No agency , The called method is not controlled by the transaction management code

The so-called proxy is actually whether it has used dependency injection , If we manually new An object , Or call the method of this class directly without proxy .

The following code can print out the current transaction hashCode, If hashCode The same is considered to be the same transaction .

TransactionAspectSupport.currentTransactionStatus().hashCode()

• You can put it on top funOne and funTwo Inside , Found the last print out hashCode Is not the same .

• If we call funTwo When , Not used @Autowired The way , But use new The way , You'll find it printed hashCode It's the same .

• • TestServiceTwo two = new TestServiceTwo();
• • two.funTwo();

• If you remove the method funTwo above @Transactional annotation , Print again hashCode It's the same .

• If you don't call funTwo, But to call and funOne similar （ Same class ） Of funThree, Printed hashCode It's the same .

notes ： If hashCode If it is the same, then the description is to use a transaction .

Two 、 Nested transactions, such as fruit transactions, throw exceptions , The parent transaction will also be rolled back , And will throw an exception

Transaction rolled back because it has been marked as rollback-only

In fact, this conclusion lies in the result of this question , Finally, no data was inserted , The reason is that the parent transaction is rolled back .

funOne call funTwo,funOne Caught in funTwo It's abnormal , When funTwo When something goes wrong ,funTwo The operation should be rolled back , however funOne Eat abnormally ,funOne No exception was generated in the method , therefore funOne The operation should be submitted , The two are contradictory .

spring The transaction Association interceptor is catching funTwo The exception will be marked rollback-only by true, When funOne After execution, preparation and submission , Find out rollback-only by true, It will also roll back , And throw an exception to tell the caller .

But not absolutely , We know that the above two transactions are independent , But it's still relevant , You can understand it as related transactions （ That's what I said above spring Transaction Association interceptor …）

If we leave their transactions unconnected , It's two separate things , That is, it won't throw rollback-only This anomaly , that funOne It won't roll back .

There are many kinds of transaction propagation behavior , The default is REQUIRED, Let's change it to REQUIRES_NEW, Try again, and it turns out that a piece of data is inserted .

@Transactional(rollbackFor = Exception.class, propagation = Propagation.REQUIRES_NEW)

The spread of transactions ：

value	desc
REQUIRED ( Default )	Support current transaction , If there is no current transaction , Just create a new transaction . This is the most common choice
SUPPORTS	Support current transaction , If there is no current transaction , Just in a non transactional way
MANDATORY	Support current transaction , If there is no current transaction , Throw an exception
REQUIRES_NEW	New transaction , If there are currently transactions , Suspend current transaction
NOT_SUPPORTED	Perform operations in a non transactional way , If there are currently transactions , Suspend the current transaction
NEVER	To execute in a non transactional manner , If there are currently transactions , Throw an exception
NESTED	Support current transaction , If the current transaction exists , A nested transaction is executed , If there is no current transaction , Just create a new transaction

notes ： there Current affairs It's a little different from our general understanding , Not its parent transaction .

3、 ... and 、 If in the same transaction , Whether it's a parent method exception , Or sub method exception , All will be rolled back .（ If you put the exception try catch, Will not be ）

The same transaction here refers to （ In fact, we can print hashCode The way to judge ）

• The same class to call sub methods
• Calling another class does not @Transactional Methods

eg:

@Service
public class TestService {
    

    @Autowired
    private TestMapper testMapper;

    @Transactional(rollbackFor = Exception.class)
    public String funOne(){
    
        testMapper.insert("a");
        funThree();
        return "das";
    }

    public void funThree(){
    
        int i = 1 / 0;
    }
}