2015 24th Wednesday Spring Business 3

In a typical transaction scenario, there are several participants:

Resource Manager (RM)

ResourceManager is called RM, it is responsible for storing and managing the state of the system data resources, such as database server, JMS message server, etc. are the corresponding resource manager.

Transaction processing monitor (TP monitor)

Transaction processing Monitor, referred to as TPM or TP monitor, is responsible for reconciling transactions with multiple RM in a distributed transaction scenario. TP monitor usually corresponds to specific software middleware (middleware), with the progress of software development technology, the implementation of TP monitor is shifted from the original design and implementation based on process to object-oriented design and implementation. The Application server (application server) in the Java EE specification [4] typically assumes the role of TP Monitor.

Transaction Manager (TM)

Transaction Manager is referred to as a TM, it can be considered as the core module in TP Monitor, directly responsible for the coordination of transactions between multiple RM, and provide transaction demarcation (Transaction demarcation) [5], Transaction context propagation ( Transaction context propagation) [6] and other functional interfaces.

Application

An application that exists in its own form or that runs in a container can be considered a trigger point for a transaction boundary.

In fact, all of the above mentioned actors are not present in every transaction scenario, and if we differentiate between transaction types based on the amount of RM involved in the whole transaction, you can divide the transaction into two categories, global Transaction and local transactions Transaction), in these two types of transactions, the specific transaction participants are different.

The main difference between a local transaction and a global transaction is how much RM is involved in the transaction, not how many RM is actually in the system, which is something that needs our attention. Even if you have multiple databases (that is, RM) in your system, as long as your current transaction updates only one database's data, the current transaction should still be counted as a local transaction, not a global transaction (although in this case you can also enable global transactions).

In fact, for transaction management of a single transactional resource, you can use the RM built-in transaction support directly in a local transaction, you can also introduce TP monitor in a distributed transaction scenario, and typically, each TP monitor detects the number of RM participating in the transaction when implemented. If only a single RM participates, TP Monitor will do some optimizations to avoid the burden of the " two phase commit" protocol, but even so, for transactions involving a single transaction resource, direct adoption of the transaction support built into the RM in the local transaction, both in terms of complexity and efficiency, should be better.

In the Java local transaction scenario, the specific processing of transaction management in the system varies with the data access technology used, and we do not use the dedicated transaction API to manage transactions, but rather the "connection" [7] provided by the currently used data access technology. API to manage transactions.

Distributed transaction Management on the Java platform is primarily supported by the Java Transaction API (JTA) or Java Connector Architecture (JCA).

JTA is the Java Interface Specification for standard distributed transaction access proposed by Sun. However, the JTA specification defines only a set of Java interface definitions, the specific implementation is left to the corresponding provider to implement, each Java EE application Server needs to provide support for JTA, in addition to the use of binding to each Java EE Application Server JTA Implementation, There are several separate and mature JTA implementations on the Java platform, including:

• JOTM (http://jotm.objectweb.org/index.html)

• Atomikosatomikos (http://www.atomikos.com/home.html)

• JBoss transactions (http://labs.jboss.com/jbosstm/)

There are two ways to use JTA for distributed transaction management, which directly uses the programming transaction management of the JTA interface and the declarative transaction management based on the application server.

Spring's transactional framework separates the concerns related to transaction management in the development process and makes a reasonable abstraction of these concerns, ultimately creating a convenient yet powerful transaction management " weapon." With spring's transactional framework, we can do transactional programming according to a unified programming model, without worrying about the data access technology used and what type of transactional resources to access, and spring's transactional framework can be tightly integrated with the data access support provided by spring. Let's get you up and running between transaction management and data access, and, most of all, with spring's AOP framework, Spring's transactional framework brings us the benefits of using declarative transaction management only with CMT, without having to bind to any application server.

Spring's transaction abstraction consists of three main interfaces, Platformtransactionmanager,transactiondefinition and Transactionstatus, The three interfaces are centered on Org.springframework.transaction.PlatformTransactionManager, Org.springframework.transaction.PlatformTransactionManager is responsible for defining transaction boundaries, Org.springframework.transaction.TransactionDefinition negative Define transaction-related properties, including isolation levels, propagation behavior, etc., Org.springframework.transaction.PlatformTransactionManager will refer to the Org.springframework.transaction.TransactionDefinition attribute definition to open the The transaction state is responsible for the org.springframework.transaction.TransactionStatus of the transaction after the transaction has been opened. We can also have limited control over transactions through Org.springframework.transaction.TransactionStatus.

Transactiondefinition provides the following options for transactional propagation behavior, except that propagation_nested is unique to spring, and other propagation behaviors are essentially the same semantics as CMT:

• propagation_required. If a transaction is currently present, the current transaction is joined, and if no transaction exists, a new transaction is created. In summary, be sure to run at least one transaction. Propagation_required usually acts as the default transaction propagation behavior.

• propagation_supports. If a transaction is currently present, the current transaction is joined and is executed directly if no transaction is currently present. For some query methods, Propagation_supports is usually a more appropriate choice for propagation behavior. If the current method executes directly, no transaction support is required, and if the current method is called by another method, and the other method initiates a transaction, using Propagation_supports guarantees that the current method can join the current transaction and gain insight into the current transaction's updates to the data resource. For example, A.service () will first update the database and then call B.service () to query, so B.service () can read A.service () if it is a propagation_supports propagation behavior. The latest update results, and if you use the propagation_not_supported mentioned later, B.service () will not be able to read the latest update results because the transaction for A.service () has not been committed at this time ( Unless the isolation level is READ UNCOMMITTED):

• propagation_mandatory. Propagation_mandatory enforces that a transaction is currently present and throws an exception if it does not exist. If a method requires transactional support, but does not manage transaction commit or rollback itself, it is more appropriate to use propagation_mandatory. You can learn more about the possible scenarios of propagation_mandatory by comparing the two propagation behaviors of required and mandatory in the JAVA TRANSACTION DESIGN strategies Book.

• propagation_requires_new. A new transaction is created regardless of whether a transaction currently exists. If a transaction is currently present, the current transaction is suspended (suspend). If a business object does not want to affect the outer transaction, Propagation_requires_new should be the appropriate choice, for example, assuming that the current business method needs to update some log information to the database, but even if these log information updates fail, We also do not want to affect the successful submission of the outer transaction because of the transaction rollback of the business method, because in this case the transaction success of the current business method is irrelevant to the outer transaction.

• propagation_not_supported. The current transaction is not supported, but is executed without a transaction. If a transaction is currently present, the current transaction is in principle suspended (suspend), but depends on whether the corresponding Platformtransactionmanager implementation class supports the pending (suspend) of the transaction. For more information, refer to Transactiondefinition's Javadoc documentation. The difference between propagation_not_supported and propagation_supports can be referred to the instance content of the Propagation_supports section.

• Propagation_never. You never need a transaction that currently exists and throws an exception if the current transaction exists.

• propagation_nested. If the current transaction exists, it is executed in a nested transaction of the current transaction, otherwise it behaves like propagation_required, which is to create a new transaction and execute it in the newly created transaction. Propagation_nested looks as if it is similar to Propagation_requires_new's behavior, in fact there are differences between them. The new transaction created by Propagation_requires_new belongs to the same "grade" as the outer transaction, i.e. the status of the two is the same, and when the newly created transaction runs, the outer transaction is temporarily suspended (suspend); Propagation_ The nested transaction created by nested is not, it is parasitic on the current outer layer of the transaction, its status is smaller than the current outer layer of the transaction, when the internal nested transactions run, the outer transaction is also out of the active state:

  That is, propagation_requires_new the newly created transaction executes within the current outer transaction, but the newly created transaction exists independently of the current outer transaction, and the two have separate states without interfering with each other; Propagation_ The transaction created by nested belongs to the inner Child transaction (sub-transaction) of the current outer transaction, and the processing content of the inner sub-transaction is part of the current outer transaction and cannot exist independently of the outer transaction and has a transactional state with the outer transaction. I think that's why it's called internal nesting.

  Propagation_nested The possible scenario is that you can divide a large transaction into smaller transactions, and the outer transaction can select different execution processes based on the execution results of each internal nested transaction. For example, the business method of a business object A.service () might call other business methods B.service () to insert a batch of business data into the database, but when the business method that inserted the data has an error (such as a primary key conflict), we can catch the exception thrown by the previous method in the current transaction. Then select another business method that updates the data C.service () to execute, at which point we can specify the propagation behavior of the B.service () and C.serivce () methods as propagation_nested
  

  However, not all Platformtransactionmanager implementations support the propagation behavior of the propagation_nested type, Only Org.springframework.jdbc.datasource.DataSourceTransactionManager is now supported with the JDBC3.0 database driver (of course, The database and corresponding drivers also need to be supported, and some jtatransactionmanager may also provide support, but the JTA specification does not require support for nested transactions.

  Platformtransactionmanager is the core component of the Spring Transaction abstraction framework, and we have already mentioned its definition and role, so In this section, we may wish to pay more attention to the whole hierarchy of platformtransactionmanager and the implementation classes for different data access technologies.

  Platformtransactionmanager the whole abstract system is based on the strategy model, the Platformtransactionmanager defines the transaction as a unified abstraction, and the implementation of the specific defined strategy is referred to the concrete implementation class. Let's take a look at what implementation classes are available for us to use.

  The implementation classes of Platformtransactionmanager can be divided into two branches for local transactions and global transactions:

  • a Platformtransactionmanager implementation class for local transactions. Spring provides out-of-the-box Platformtransactionmanager implementation support for various data access technologies, with the following list showing the relationship of various data access technologies to their corresponding implementation classes:

    Data access Technology	Platformtransactionmanager Implementation Class
    Jdbc/ibatis	Datasourcetransactionmanager
    Hibernate	Hibernatetransactionmanager
    Jdo	Jdotransactionmanager
    JPA (Java persistence API)	Jpatransactionmanager
    TopLink	Toplinktransactionmanager
    Jms	Jmstransactionmanager
    JCA Local Transaction	Ccilocaltransactionmanager

    
    Of these implementation classes, Ccilocaltransactionmanager may be a relatively rare implementation, CCI means common Client Interface, Ccilocaltransactionmanager is primarily a JCA-oriented local transaction (local Transaction), and the book does not intend to elaborate on the integration of JCA, if the reader needs to use the JCA for EIS in the actual project ( Enterprise Information System integration, you can get enough information from spring's reference documentation to use the JCA integration support provided by spring.

    With these implementation classes, when we use the Spring Transaction abstraction framework for transaction management, we only need to select the corresponding Platformtransactionmanager implementation class based on the data access technology currently in use.

  Excerpt from: http://www.cnblogs.com/superjt/archive/2013/05/20/3088847.html

2015 24th Wednesday Spring Business 3