Thoroughly understand the handwritten implementation of Spring transaction design ideas

foreword

A transaction is an abstraction that describes a set of operations, such as a set of operations on a database, that either all succeed or all fail. Transactions have 4 characteristics: Atomicity (atomicity), Consistency (consistency), Isolation (isolation), Durability (durability). In actual development, most of our transaction applications are in the database operation link, especially Spring encapsulates and manages database transactions. Spring's support for transactions is indeed very powerful, but in essence: whether a transaction takes effect depends on whether the underlying database supports it (for example, MySQL's MyISAM engine does not support transactions, what can Spring do!), and at the same time, multiple operations of a transaction need to be on the same Connection. Transactions are also often controlled at the business logic layer. This blog will analyze how the underlying Spring transaction helps us easily complete transaction management by writing a Demo!

Thoroughly understand the handwritten implementation of Spring transaction design ideas

Let's take a look at the project structure first:

ConnectionHolder

In Spring, do we sometimes need to configure multiple data sources DataSource? Obviously, Spring needs to get the pipeline Connection for operating the database through DataSource, which is somewhat similar to JNDI lookup.

Here, the ConnectionHolder class is used to complete this process. What needs to be considered is that under multi-threading, there is obviously a problem. In order to avoid multi-threading problems, do we use thread-safe Map, such as ConcurrentHashMap, what is our real purpose? It is to ensure that under one thread, multiple operations of a transaction get a Connection. Obviously, using ConcurrentHashMap cannot guarantee at all!

Spring is very smart, she provides an idea to solve, look at the code below!

SingleThreadConnectionHolder

Originally, the thread is not safe. By encapsulating it in ThreadLocal, it immediately becomes a local variable of the thread. It is not only safe, but also ensures that the Connection obtained by the operation under a thread is the same object! This kind of thinking is indeed very ingenious, and it is also a way of thinking of lock-free programming!

TransactionManager

TransactionManager, we often configure this in Spring, the transaction manager!

UserAccountDao、UserOrderDao

Here, through these two DAOs, I want to simulate two operations of account purchase and order placement in one transaction.

UserService

At this point, you can clearly see a microcosm of Spring transaction management!

Test

Here, it is mainly to simulate Spring's injection and multi-user concurrent requests.

operation result

You can find that multiple operations of a transaction in a thread use the same Connection!

Well, here, can you understand the idea of ​​Spring's implementation of transactions?

Here, Xiaobian recommends a good place to learn Java technology for free. The course covers Java, Redis, MongoDB, MySQL, Zookeeper, Spring Cloud, Dubbo/Kafka, Hadoop, Hbase, Flink and other high-concurrency distributed and big data , machine learning and other technologies.

Transfer gate: https://ke.qq.com/course/293193?flowToken=1002121

Guess you like

Origin http://43.154.161.224:23101/article/api/json?id=324820317&siteId=291194637