Spring IOC and AOP, dynamic proxy techniques, thread-safety issues for beans, transaction mechanisms

If you implement a Transactional annotation with @Transactional, Spring will use AOP to start the transaction before executing your method. After executing, spring will decide whether to roll back or commit the transaction based on whether your method fails

// Start a transaction

Execute the code for method A, followed by the code for method B

// Commit or rollback the transaction

// Start transaction 1

// Execute some code within method A, doSomethingPre()

// Start transaction 2

Execute some code in method B

// Commit or rollback transaction 2

// Execute some code within method A, doSomethingPost()

// Commit or rollback transaction 1

// Start a transaction

// Execute some code within method A, doSomethingPre()

// Set a rollback point savePoint

Execute some code in method B

// If an exception is thrown in method B, roll back to savePoint

// Execute some code within method A, doSomethingPost()

// Commit or rollback the transaction

Nested transactions. If the outer transaction is rolled back, the inner transaction will be rolled back as well. But the inner transaction, if rolled back, simply rolls back its own code

1, PROPAGATION_REQUIRED: Create a new transaction if there is no transaction currently, PROPAGATION_REQUIRED: Join the transaction if there is one, this setting is the most commonly used.

(2) PROPAGATION_SUPPORTS: Supports the current transaction. If a transaction exists, join it, and execute it as a non-transaction if no transaction exists. ‘

③ PROPAGATION_MANDATORY: The current transaction is supported. If a transaction exists, the transaction is added, and if no transaction exists, an exception is thrown.

(4) PROPAGATION_REQUIRES_NEW: Creates a new transaction, regardless of whether one currently exists.

⑤ PROPAGATION_NOT_SUPPORTED: Execute an operation non-transactionally, and suspend the current transaction if it exists.

⑥ PROPAGATION_NEVER: Executes non-transactionally, and throws an exception if a transaction currently exists.

⑦ PROPAGATION_NESTED: Executes within a nested transaction if a transaction currently exists. If there are no transactions currently, the REQUIRED attribute is executed.

Go out to interview, business communication mechanism

For example, we now have A piece of business logic where method A calls method B, and what I want is if method A fails, we just roll back method A, we can’t roll back method B, we have to use REQUIRES_NEW propagation so that their transactions are different

Method A calls method B, and if an error occurs, method B can only roll back itself, and method A can roll back with method B, NESTED transactions