preface

The Spring transaction section is a very basic one, and it comes up very frequently in interviews. If you don’t understand it well and answer it poorly, you will give the impression that you are not capable of more complex functions and are only suitable for simple CRUD operations.

But now that there are so many tools to generate code, simple CRUDS don’t even need to be written by humans once the template is edited, and things don’t make sense anymore… “You’re great, but you’re not right for us. Look forward to working with us in the future.” “Go home and wait to hear from you.”

The nature of Spring transactions

First, consider how transactions were handled when we were not using the Spring framework. Do you want to use JDBC to handle transactions?

  • Get database connection;
  • Start a transaction;
  • Perform the CRUD;
  • Commit or roll back a transaction;
  • Close the connection

Once we use Spring to manage transactions, the steps are less complicated, and with an annotation we can focus on writing the business logic and let Spring’s AOP do the repetitive work for us.

Therefore, the essence of Spring transactions is the management of database transactions, and if the database does not support transactions, then Spring cannot provide transactions.

Frequently seen exam

  1. Is Spring’s transaction isolation level the same as database transaction isolation level?

    Answer: It’s the same concept

  2. Repeatable Read = Repeatable Read; Read Commited = Read Commited = Read Commited = Read Commited = Read Commited = Read Commited

    Answer: Use the isolation level configured by Spring, provided that the database supports the isolation level configured by Spring. Otherwise, use the isolation level configured by the database

    1.

    Once you understand the nature of Spring transactions, the first question comes naturally.

    The source code is so written, interested can go to see the source code

    ③ Database transaction isolation level:

    • Read Uncommitted: Allows uncommitted changes to be Read. May cause dirty, phantom, or unrepeatable reads.
    • Read COMMITTED: Allows reading from committed concurrent transactions. Dirty reads are prevented, but phantom and non-repeatable reads may still occur.
    • Repeatable Read: Ensure that the transaction can Read the same value from a field many times. During the duration of the transaction, it is forbidden for other transactions to update the field to avoid dirty reads and unrepeatable reads, and phantom Read problems still occur.
    • Serializable: The strictest transaction isolation level, requiring all transactions to be executed sequentially and not concurrently, avoiding dirty reads, unrepeatable reads, and phantom reads.

    ④ Spring transaction isolation level:

    • ISOLATION_DEFAULT: Use the default isolation level of the back-end database;
    • ISOLATION_READ_UNCOMMITTED: Read uncommitted of the corresponding database.
    • ISOLATION_READ_COMMITTED: Read COMMITTED of the corresponding database.
    • ISOLATION_REPEATABLE_READ: Repeatable Read of the corresponding database;
    • ISOLATION_SERIALIZABLE: Serializable of the corresponding database;

  3. In the Service layer, a method with transaction management enabled calls another method with transaction management enabled. There is no special transaction configuration.

    A: Start a transaction, because Spring’s default transaction propagation mechanism is PROPAGATION_REQUIRED, add the current transaction if it exists in the context, and create a new transaction if none exists.

    There are seven different transaction propagation mechanisms in Spring. We don’t need to memorize all of them, but the default is to know that we can look up other transaction propagation mechanisms and choose the appropriate one to use when we have a special need for a transaction.

  4. When do Spring transactions fail?

    Refer to this article:

  5. How do I guarantee connection uniqueness within Spring transactions?

    A: To ensure the uniqueness of a Connection, Spring stores the connection to a ThreadLocal when a transaction is started, and retrievals the connection from a ThreadLocal when it is needed. This ensures that all operations in one thread fetch the same object.

  6. Where can the @Transactional annotation be placed?

    A: Methods, classes, and interfaces can be added. Generally, they are added to methods, not interfaces. If they are added to classes, then all public methods of that class are managed by transactions

If you have any questions, please search [Hugh’s whiteboard] on wechat and send me a private message. Let’s discuss and learn together