Shulou(Shulou.com)06/03 Report--

This article mainly introduces "how to understand the Transaction transaction module in the MyBatis source code". In daily operation, I believe many people have doubts about how to understand the Transaction transaction module in the MyBatis source code. Xiaobian consulted all kinds of materials and sorted out simple and easy-to-use methods of operation. I hope it will be helpful for you to answer the doubt of "how to understand the Transaction transaction module in the MyBatis source code". Next, please follow the editor to study!

Catalogue

1. Review

2. Transaction module

2.1 transaction interface

2.2 MyBatis transaction types

2.3 JDBC transaction model

2.4 about autocommit

2.5 question

1. Review

The Environment environment class was introduced earlier, which is actually a singleton class. There will only be a unique environment instance after the MyBatis is enabled. Although we can configure multiple environments in the Configuration configuration file, only one of them will exist in the project operation. Generally, there will be three major environments: the development environment, the test environment and the production environment. Can they be set to the configuration file and use the development environment during development? The test environment is used for testing, and the production environment can be used for formal operation.

I also mentioned earlier that there are three fields in the Environment class. In addition to id, TransactionFactory and DataSource are more complex modules. This time we introduce the Transaction module (that is, the transaction module).

2. Transaction module

The transaction module is located in the org.apache.ibatis.transaction package, and the classes in this package are transaction-related classes:

Org.apache.ibatis.transaction

-org.apache.ibatis.transaction.jdbc

-JdbcTransaction.java

-JdbcTransactionFactory.java

-org.apache.ibatis.transaction.managed

-ManagedTransaction.java

-ManagedTransactionFactory.java

-Transaction.java

-TransactionException.java

-TransactionFactory.java

You can also see from the class structure above that MyBatis's transaction module is in factory mode.

2.1 transaction interface

Both Transaction and TransactionFactory located in the org.apache.ibatis.transaction package are interface classes.

Transaction is a transaction interface in which four methods are defined:

Commit ()-transaction commit

RollBack ()-transaction rollback

Close ()-closes the database connection

GetConnection ()-get the database connection

The following code is shown:

Package org.apache.ibatis.transaction;import java.sql.Connection;import java.sql.SQLException;/** * transaction, which wraps a Connection with commit,rollback,close method * there are two transaction manager types in MyBatis (that is, type= "[JDBC | MANAGED]"): * / public interface Transaction {Connection getConnection () throws SQLException; void commit () throws SQLException; void rollback () throws SQLException; void close () throws SQLException;}

TransactionFactory is a transaction factory interface where three methods are defined:

SetProperties (Properties props)-sets properties

NewTransaction (Connection conn)-create a transaction instance

NewTransaction (DataSource dataSource,TransactionIsolationLevel level,boolean autoCommit)-create a transaction instance

The following code is shown:

Package org.apache.ibatis.transaction;import java.sql.Connection;import java.util.Properties;import javax.sql.DataSource;import org.apache.ibatis.session.TransactionIsolationLevel;/** * transaction factory * / public interface TransactionFactory {/ / set properties void setProperties (Properties props); / / create Transaction Transaction newTransaction (Connection conn) based on Connection; / / create Transaction Transaction newTransaction (DataSource dataSource, TransactionIsolationLevel level, boolean autoCommit) based on data source and transaction isolation level;}

The purpose of Transacrion interface definition is to abstract specific transaction types and to facilitate extension; TransactionFactory, like it, is an abstraction of transaction factories, as well as an extension implementation of specific types of transaction factories.

2.2 MyBatis transaction types

At this point, we have to mention the two transaction types built into MyBatis and the corresponding transaction factories. Remember that the environment configuration information given in the previous article has this sentence:

The tag here is used to define the transaction type used by the project, which is specified by the type attribute, where the "JDBC" type transaction is specified, and of course MyBatis provides another "MANAGED" type transaction.

-JDBC

-MANAGED

Here "JDBC" and "MANAGED" are aliases registered in the type alias registry of the Configuration configuration class, and their corresponding classes are: JdbcTransactionFactory.class and ManagedTransactionFactory.class. The specific configuration is as follows:

TypeAliasRegistry.registerAlias (JDBC, JdbcTransactionFactory.class); typeAliasRegistry.registerAlias (MANAGED, ManagedTransactionFactory.class)

The above code is defined in the no-parameter constructor of the Configuration class, which is used here for demonstration only and will be described later.

Here to mention: the principle of type alias register quota is to save aliases and specific class types in a HashMap in the way of key-value pairs, so that as long as you know aliases (keys), you can get the corresponding values (Class types) from Map, which is very simple!

Now all you need to know is that MyBatis can find the corresponding transaction factory class directly according to the transaction type you set in the configuration file.

The two transaction types mentioned above are interpreted below.

-JDBC transaction model: JdbcTransaction

-MANAFED transaction model: ManagedTransaction

The difference between the two is that the former directly uses the JDBC provided by JDK to manage all aspects of the transaction: commit, rollback, close, etc., while the latter does nothing, so what's the point of the latter? of course it's important.

When we use MyBatis alone to build the project, we configure the environment in the Configuration configuration file, where we set the transaction type to JDBC, which means that when MyBatis is used alone, we need to use a transaction model of JDBC type, because all aspects of the transaction are defined in this model, which can be used to complete the various operations of the transaction.

The transaction model of MANAGED type is actually a managed model, that is to say, it does not implement any transaction functions, but is hosted and implemented by other frameworks. You may not understand that the specific implementation of this transaction is left to frameworks such as Spring, and after using the SSM integration framework, it is no longer necessary to configure environment information separately (including transaction configuration and data source configuration). Because there is code in the integrated jar package (mybatis-spring.jar) that covers this part of the logic in mybatis, the reality is that even if you explicitly set the relevant configuration information, the system will turn a blind eye to it.

The significance of hosting is obvious, and it is designed for integration.

The purpose of learning MyBatis is precisely because of its flexibility and ability to integrate seamlessly with frameworks such as Spring, so the content about JDBC transaction modules is obviously no longer the focus of MyBatis functionality, and may only be used in a small number of systems that use MyBatis alone.

2.3 JDBC transaction model

Although JDBC transaction types are rarely used, as an integral part of MyBatis, we still need to understand that the implementation of JDBC transactions is a re-encapsulation of the JDBC transaction module provided in JDK to apply to the MyBatis environment.

The JDBC transaction module in MyBatis consists of two parts, namely JDBC transaction factory and JDBC transaction. The whole transaction module adopts abstract factory pattern, so each specific transaction processing module must have its own transaction factory. Transaction module instances are created through transaction factories (transaction factories encapsulate the creation of specific transaction instances).

First, let's take a look at the JDBC transaction factory: JdbcTransactionFactory

JdbcTransactionFactory inherits from the TransactionFactory interface and implements all of its methods. One method for setting properties and two methods for creating new transaction instances (with different parameters) are simple in content and simple in effect.

The setProperties () method is used to set the property, which is called when the transaction tag is parsed in XMLConfigBuilder, and is used to parse the subordinate attribute tag of the transaction tag (normally we don't set it, but if we do, it overrides the default setting in MyBatis) and sets it to the transaction instance we created. However, for the JDBC transaction model, there is no execution code in the setting property method of the transaction factory, which means that the JDBC transaction module does not support the function of setting properties, even if you set some information in the configuration file, it will not have any effect.

So what's the use of this method? As mentioned earlier, this setting is used to override the default setting, but it is not supported by the JDBC transaction module, but it does not mean that other transaction models do not support it, and this method can also be used for functional extension.

The other two methods are obvious, which are the production methods used to create JDBC transaction instances, but with different parameters, the method is overloaded. One of the production methods simply passes an instance Connection, which represents a database connection. The other method needs to pass three parameters (DataSource, TransactionIsolationLevel, boolean). In fact, these correspond to the two production methods of SqlSession in MyBatis, and their parameters correspond to one by one here. This part will be introduced later and will not be repeated here.

Then let's look at the JDBC transaction class: JdbcTransaction

There are four parameters:

Protected Connection connection; protected DataSource dataSource; protected TransactionIsolationLevel level; protected boolean autoCommmit

These four parameters correspond to a total of four parameters in the two production methods in the transaction factory, and the corresponding two constructors are defined in the transaction class, and the instance is assigned at the same time:

Public JdbcTransaction (DataSource ds, TransactionIsolationLevel desiredLevel, boolean desiredAutoCommit) {dataSource = ds; level = desiredLevel; autoCommmit = desiredAutoCommit;} public JdbcTransaction (Connection connection) {this.connection = connection;}

Secondly, the Transaction interface is implemented in this class, including four methods, three functional methods, and a method to obtain database connection. The three functional methods are commit, rollback, and close.

@ Override public void commit () throws SQLException {if (connection! = null & &! connection.getAutoCommit ()) {if (log.isDebugEnabled ()) {log.debug ("Committing JDBC Connection [" + connection + "]");} connection.commit () } @ Override public void rollback () throws SQLException {if (connection! = null & &! connection.getAutoCommit ()) {if (log.isDebugEnabled ()) {log.debug ("Rolling back JDBC Connection [" + connection + "]");} connection.rollback ();} @ Override public void close () throws SQLException {if (connection! = null) {resetAutoCommit () If (log.isDebugEnabled ()) {log.debug ("Closing JDBC Connection [" + connection + "]");} connection.close ();}}

Through the observation of these three methods, it can be found that connection is used for specific operations, so the premise of these methods is to obtain the connection database connection first, and the getConnection () method is used to obtain Connection.

@ Override public Connection getConnection () throws SQLException {if (connection = = null) {openConnection ();} return connection;}

The openConnection () method is called in the above method:

Protected void openConnection () throws SQLException {if (log.isDebugEnabled ()) {log.debug ("Opening JDBC Connection");} connection = dataSource.getConnection (); if (level! = null) {connection.setTransactionIsolation (level.getLevel ());} setDesiredAutoCommit (autoCommmit);}

It can be seen that the connection is obtained from the data source dataSource, and finally the setDesiredAutoCommit () method is called:

Protected void setDesiredAutoCommit (boolean desiredAutoCommit) {try {if (connection.getAutoCommit ()! = desiredAutoCommit) {if (log.isDebugEnabled ()) {log.debug ("Setting autocommit to" + desiredAutoCommit + "on JDBC Connection [" + connection + "]");} connection.setAutoCommit (desiredAutoCommit) } catch (SQLException e) {/ / Only a very poorly implemented driver would fail here, / / and there's not much we can do about that. Throw new TransactionException ("Error configuring AutoCommit." + "Your driver may not support getAutoCommit () or setAutoCommit ()." + "Requested setting:" + desiredAutoCommit + ".Cause:" + e, e);}}

The purpose of this method is to assign values (true or false) to autocommit in connection.

From this point of view, the three parameters we provide to create a transaction instance are for the connection service, in which DataSource is used to obtain the Connection instance, and TransactionIsolationLevel (transaction level) and boolean (autocommit) are used to populate the connection. We get a satisfactory Connection instance through three parameters, and then we can use this instance for transaction operations: commit, rollback, and close.

2.4 about autocommit

In the previous code, we can see that a method was called before the close operation: resetAutoCommit ():

Protected void resetAutoCommit () {try {if (! connection.getAutoCommit ()) {/ / MyBatis does not call commit/rollback on a connection if just selects were performed / / Some databases start transactions with select statements / / and they mandate a commit/rollback before closing the connection. / / A workaround is setting the autocommit to true before closing the connection. / / Sybase throws an exception here. If (log.isDebugEnabled ()) {log.debug ("Resetting autocommit to true on JDBC Connection [" + connection + "]");} connection.setAutoCommit (true);}} catch (SQLException e) {log.debug ("Error resetting autocommit to true" + "before closing the connection. Cause:" + e);}}

Here is a commentary relative to autocommit. If autocommit is set to true, the database will execute each SQL statement as a transaction. In order to commit multiple SQL as a transaction, autocommit must be set to false, and then commit manually. Generally speaking, in our project, we need to set autocommit to false, which is about to turn off autocommit and use manual submission.

This method determines whether the autocommit setting (true or false) in the connection instance is true or false. If it is false, it indicates that autocommit is not performed, then reset and reset it to true. (the default for autocommit is true.) this operation is performed before connection is turned off. It can be seen as a reset operation before the connection is closed.

2.5 question

What is the role of the constructor that takes Connection as a parameter among the two constructors provided in JdbcTransaction?

We need to automatically assemble a complete Connection and use it as a parameter to produce a transaction instance. In what scenarios is this used?

At this point, the study on "how to understand the Transaction transaction module in the MyBatis source code" is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.