I recently learned java affairs, and saw a series of blogs from a senior that was good, and reprinted it as a record
Reprint address: http://www.davenkin.me/post/2013-02-16/40048284001
(1) Basic problems of Java transaction processing
(4) Successful case (implement a thread-safe TransactionManager by yourself)
(6) Use dynamic proxy (Dynamic Proxy) to complete the transaction
(7) Use Transactional annotations like Spring
(8) Introduction to distributed transactions (Spring+JTA+Atomikos+Hibernate+JMS)
Part 1: Basic Problems of Java Transaction Processing
How simple is transaction processing in Java? When using EJB, transactions play a role that we hardly notice; when using Spring, we only need to configure a TransactionManager, and then add Transactional annotations to the methods that require transactions. Transaction processing in Java is so simple because the framework does so much work for us behind the scenes. In this way, although we can complete the development work quickly, once there is a problem with the program, after a while of google and stackoverflow, you may still be at a loss. As a programmer with technical pursuits, you should understand the underlying workings of Java transactions.
This is a series of articles about Java transaction processing, please download the github source code via:
git clone https://github.com/davenkin/java_transaction_workshop.git
(1) Basic problems of Java transaction processing
Java interacts with the database through JDBC. This is a technology that most programmers do not use directly today. We prefer to use Hibernate and Mybatis. However, they all require JDBC to communicate with the database at the bottom, and the same is true for transaction processing. So, let's first take a look at the transaction processing API provided by JDBC.
(1) Transaction API provided by JDBC
There are very few transaction processing APIs provided by JDBC. Please don't be discouraged by the pile of source code for transaction processing in Spring. The transaction processing functions provided by these frameworks are mainly completed by the methods of the Connection class in the final analysis:
Connection.setAutoCommit(boolean);
Connection.commit();
Connection.rollback();
In Spring's transaction processing source code, many deal with multithreading, and some use some design patterns. Don't panic, in this series (except series 8), you will not see any shadow of Spring, we will learn Java transactions through simple code, after learning, you can read Spring's transaction processing source code, and then Comparing the transaction processing principle in this series with Spring, you will find that the problems that Spring has to face and deal with are also the problems encountered in this series of articles.
(2) Local transactions and distributed transactions
Local (Local Transaction) transaction refers to a transaction involving only one data source, such as only a database or only JMS; Distributed Transaction (Distributed Transaction) refers to a transaction involving multiple data sources at the same time, such as an operation that requires simultaneous access to the database and through JMS sends a message, or an operation requires simultaneous access to two different databases. For distributed transactions, Java provides the JTA specification, which works differently than local transactions. In view of the fact that Java transactions are local transactions in most cases, this series mainly explains local transactions, and there are introductory examples of distributed transactions in series 8.
(3) Thread safety
Thread safety is a major difficulty in Java transaction processing. For example, a DAO class maintains a Connection instance variable. Two threads use the DAO class to interact with the database at the same time. One of them closes the Connection after using it, while the other The thread is using the Connection to access the database, and another thread's access to the database will fail. In subsequent articles in this series, we will learn how to deal with such problems and develop thread-safe programs.
(4) Service layer and DAO layer
通常来说，数据持久化层又分为Service层和DAO层，Service层用于完成与业务逻辑有关的工作，并且Service层包含了工作单元（Unit of work），也即Service层中的方法为事务作用的边界；DAO层用于完成对数据库的实际操作（增删改查）。有时在使用Hibernate或是JPA时我们也会直接在Service层访问数据库而省略掉DAO层。在本系列中，我们会用一个BankService例子贯穿始终。该BankService用于将用户银行账户（Bank Account）中的存款转帐到该用户的保险账户（Insurance Account）中，两个账户对应有不同的数据库表。
BankService需要两个DAO类协同起来工作，一个负责银行账户表的操作，另一个负责保险账户表操作，这是一个典型的事务处理例子。在下一篇文章中，我们将学习一个关于该BankService事务处理失败的案例。