Spring跨数据库事务管理
Spring跨数据库事务管理
XAConnectionFactoryEnabled
org.springframework.transaction.jta.WebLogicJtaTransactionManager
JTA
The Java Transaction API (JTA), one of the Java Enterprise Edition (Java EE) APIs, enables distributed transactions to be done across multiple X/Open XA resources in a Java environment. JTA is a specification developed under the Java Community Process as JSR 907. JTA provides for:
- demarcation of transaction boundaries
- X/Open XA API allowing resources to participate in transactions.
XA
In computing, the XA standard is a specification by The Open Group for distributed transaction processing (DTP). It describes the interface between the global transaction manager and the local resource manager. The goal of XA is to allow multiple resources (such as databases, application servers, message queues, transactional caches, etc.) to be accessed within the same transaction, thereby preserving the ACID properties across applications. XA uses a two-phase commit to ensure that all resources either commit or rollback any particular transaction consistently (all do the same).
XA stands for "eXtended Architecture" and is an X/Open group standard for executing a "global transaction" that accesses more than one back-end data-store. XA specifies how a transaction manager will roll up the transactions against the different data-stores into an "atomic" transaction and execute this with the two-phase commit (2PC) protocol for the transaction. Thus, XA is a type of transaction coordination, often among databases. ACID Transactions are a key feature of databases, but typically databases only provide the ACID guarantees for activities that happen inside a single database. XA coordination allows many resources (again, often databases) to participate in a single, coordinated, atomic update operation.
The XA specification describes what a resource manager must do to support transactional access. Resource managers that follow this specification are said to be XA-compliant.
The XA specification was based on an interface used in the Tuxedo system developed in the 1980s, but adopted by several systems since then.[1]
n transaction processing, databases, and computer networking, the two-phase commit protocol (2PC) is a type of atomic commitment protocol (ACP). It is a distributed algorithm that coordinates all the processes that participate in a distributed atomic transaction on whether to commit or abort (roll back) the transaction (it is a specialized type of consensus protocol). The protocol achieves its goal even in many cases of temporary system failure (involving either process, network node, communication, etc. failures), and is thus widely utilized.[1][2][3] However, it is not resilient to all possible failure configurations, and in rare cases user (e.g., a system's administrator) intervention is needed to remedy an outcome. To accommodate recovery from failure (automatic in most cases) the protocol's participants use logging of the protocol's states. Log records, which are typically slow to generate but survive failures, are used by the protocol's recovery procedures. Many protocol variants exist that primarily differ in logging strategies and recovery mechanisms. Though usually intended to be used infrequently, recovery procedures comprise a substantial portion of the protocol, due to many possible failure scenarios to be considered and supported by the protocol.
In a "normal execution" of any single distributed transaction, i.e., when no failure occurs, which is typically the most frequent situation, the protocol consists of two phases:
- The commit-request phase (or voting phase), in which a coordinator process attempts to prepare all the transaction's participating processes (named participants, cohorts, or workers) to take the necessary steps for either committing or aborting the transaction and to vote, either "Yes": commit (if the transaction participant's local portion execution has ended properly), or "No": abort (if a problem has been detected with the local portion), and
- The commit phase, in which, based on voting of the cohorts, the coordinator decides whether to commit (only if all have voted "Yes") or abort the transaction (otherwise), and notifies the result to all the cohorts. The cohorts then follow with the needed actions (commit or abort) with their local transactional resources (also called recoverable resources; e.g., database data) and their respective portions in the transaction's other output (if applicable).
Note that the two-phase commit (2PC) protocol should not be confused with the two-phase locking (2PL) protocol, a concurrency control protocol.
WebLogicJtaTransactionManager
Special JtaTransactionManager variant for BEA WebLogic (9.0 and higher). Supports the full power of Spring's transaction definitions on WebLogic's transaction coordinator, beyond standard JTA: transaction names, per-transaction isolation levels, and proper resuming of transactions in all cases.
Uses WebLogic's specialbegin(name)method to start a JTA transaction, in order to make Spring-driven transactions visible in WebLogic's transaction monitor. In case of Spring's declarative transactions, the exposed name will (by default) be the fully-qualified class name + "." + method name.
Supports a per-transaction isolation level through WebLogic's corresponding JTA transaction property "ISOLATION LEVEL". This will apply the specified isolation level (e.g. ISOLATION_SERIALIZABLE) to all JDBC Connections that participate in the given transaction.
Invokes WebLogic's specialforceResumemethod if standard JTA resume failed, to also resume if the target transaction was marked rollback-only. If you're not relying on this feature of transaction suspension in the first place, Spring's standard JtaTransactionManager will behave properly too.
By default, the JTA UserTransaction and TransactionManager handles are fetched directly from WebLogic'sTransactionHelper. This can be overridden by specifying "userTransaction"/"userTransactionName" and "transactionManager"/"transactionManagerName", passing in existing handles or specifying corresponding JNDI locations to look up.
转载于:https://my.oschina.net/u/138995/blog/176368