[Java eeconf 2016] spring jta principles of work with transactions. Dmytro Sokolov
•Télécharger en tant que PPTX, PDF•
3 j'aime•1,287 vues
cover following topics: the internal structure of Spring JTA; possible configuration with Spring AOP; all features of the framework for handling transactions; the types of sources of transactions and how to work with them; distributed transactions with multiple data sources; integration with Spring JdbcTemplate, Hibernate, JMS.
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
En vedette
En vedette (13)
Similaire à [Java eeconf 2016] spring jta principles of work with transactions. Dmytro Sokolov
Similaire à [Java eeconf 2016] spring jta principles of work with transactions. Dmytro Sokolov (20)
Dernier
Dernier (20)
[Java eeconf 2016] spring jta principles of work with transactions. Dmytro Sokolov
- 1. Spring JTA: Principles of work with transactions .com
- 2. .com Dmytro Sokolov ▷10 years Java Developer ▷3 years Trainer & Mentor ▷Java Trainer / Lead Software Engineer ▷Full-stack experience ▷Project: BecomeJavaSenior.com ▷email: becomejavasenior@gmail.com Hello! .com
- 3. .com.com
- 4. .com Agenda ▷The internal structure of Spring JTA; ▷Possible configuration with Spring AOP; ▷Transaction Concepts ▷Benefits of Spring JTA ▷Best Practices and pitfalls
- 5. .com The internal structure of Spring JTA
- 6. .com Transaction What transaction models do you know?
- 7. .com Local Transaction model with JDBC connection.setAutoCommit(false); preparedStatement.executeUpdate(); connection.commit(); } catch (SQLException e) { connection.rollback();
- 8. .com Programmatic Transaction model with JPA UserTransaction utx = entityManager.getTransaction(); try { utx.begin(); businessLogic(); utx.commit(); } catch(Exception ex) { utx.rollback(); throw ex;
- 9. .com Declarative Transaction model with Spring ?
- 10. .com
- 14. .com Bean registration What does do ? 1.Execute AopAutoProxyConfigurer.configureAutoProxyCreator()
- 15. .com Bean registration What does do ? 2. Which create TransactionInterceptor
- 16. .com Bean registration What does do ? 3. Search declared TransactionManager and attached it to TransactionInterceptor
- 17. .com Bean registration What does do ? 4. Register TransactionInterceptor bean in Spring Context
- 18. .com @Transactional parsing How @Transactional annotation is parsed during runtime by Spring?
- 19. .com @Transactional parsing How @Transactional annotation is parsed during runtime by Spring? Registers the SpringTransactionAnnotationParser as default parser for the @Transactional annotation
- 20. .com Transactional interceptor invocation What does TransactionInterceptor do?
- 21. .com Transactional interceptor invocation What does TransactionInterceptor do? 1.Retrieves the transaction attributes txAttr = getTransactionAttributeSource(). getTransactionAttribute(invocation.getMethod(), targetClass);
- 22. .com Transactional interceptor invocation What does TransactionInterceptor do? 2. Gets the transaction manager from the Spring context and transaction attributes PlatformTransactionManager tm = determineTransactionManager(txAttr);
- 23. .com Transactional interceptor invocation What does TransactionInterceptor do? 4. A transaction is created by the underlying entity manager TransactionInfo txInfo = createTransactionIfNecessary(tm, txAttr, joinpointIdentification);
- 24. .com Transactional interceptor invocation What does TransactionInterceptor do? 5. The target method is invoked retVal = invocation.proceed(); } catch (Throwable ex) { completeTransactionAfterThrowing(txInfo, ex); throw ex;
- 25. .com Transactional interceptor invocation What does TransactionInterceptor do? 5. The transaction is committed commitTransactionAfterReturning(txInfo);
- 26. .com Transactional interceptor invocation What does AbstractPlatformTransactionManage r do?
- 27. .com TransactionManager invocation What does AbstractPlatformTransactionManager do? Delegates the creation and the start of the transaction itself to the underlying JpaTransactionManager.
- 28. .com TransactionManager invocation What does JpaTransactionManager do?
- 29. .com TransactionManager invocation What does JpaTransactionManager do? 1. Tries to look an existing entity manager using the entity manager factory EntityManagerHolder emHolder = TransactionSynchronizationManager.getResource( getEntityManagerFactory());
- 30. .com TransactionManager invocation What does JpaTransactionManager do? 2. Retrieves the dataSource declared for this transaction manager ConnectionHolder conHolder = TransactionSynchronizationManager.getResource( getDataSource());
- 31. .com TransactionManager invocation What does JpaTransactionManager do? 3. Delegates the creation of a new JDBC transaction to the underlying JPA Dialect Object transactionData = getJpaDialect().beginTransaction(...)
- 32. .com TransactionManager invocation What does JpaTransactionManager do? 4. Registers the current JDBC connection to the TransactionSynchronizationManager ThreadLocal map TransactionSynchronizationManager.bindResource(ge tDataSource(), conHolder);
- 33. .com TransactionManager invocation And finally execute: beginTransaction(entityManager, definition); prepareTransaction(entityManager, ...); commitTransactionAfterReturning(...);
- 34. .com Possible configuration with Spring AOP DEMO
- 36. .com X/Open XA standard XA(eXtended Architecture) is how one/multiple resources is integrating with a transaction manager
- 37. .com X/Open XA standard supports both the 1- phase commit protocol and the 2-phase commit protocol.
- 38. .com Managing single or multiple resources single resource - 1-phase commit multiple resources - 2-phase commit
- 39. .com X/Open XA standard Resources that support the XA standard expose a special object, the XA switch Interface javax.transaction.xa.XAResource
- 40. .com Transactions and threading Transactions are thread-specific
- 41. .com Transaction context At a minimum, the transaction context contains a unique transaction identifier. Depends on the relevant transaction manager implementation
- 42. .com Transaction manager The features determine the quality of service of a transaction manager: ▷Support for multiple resources ▷Distributed transactions ▷Transaction monitoring ▷Recovery from failure ▷Support for suspend/resume and attach/detach
- 43. .com Transaction managers in Spring
- 44. .com Transaction managers in Spring + JdoTransactionManager JmsTransactionManager, WebLogicJtaTransactionManager WebSphereUowTransactionManage r
- 45. .com Transaction managers in Spring PlatformTransactionManager Interface getTransaction(TransactionDefinition definition) void commit(TransactionStatus status) void rollback(TransactionStatus status)
- 46. .com Transaction managers in Spring TransactionDefinition interface isolation level and the propagation policy
- 47. .com Transaction managers in Spring TransactionStatus interface check the status of the current transaction
- 48. .com Transaction managers in Spring AbstractPlatformTransactionManager class ▷determines transaction; ▷applies propagation behavior; ▷suspends and resumes transactions; ▷checks the rollback-only flag on commit;
- 49. .com Local transaction managers in Spring can coordinate transactions over a single resource only typically embedded in the resource itself
- 50. .com Local transaction managers in Spring JDBC Spring Transaction Manager JDBC resource Oracle DB built-in Transaction Manager BEGIN, COMMIT, ROLLBACK native Oracle API
- 51. .com Local transaction managers in Spring JMS Spring Transaction Manager (facade) Resource instance of the JMS queues topics
- 52. .com Spring Transaction Architecture Standalone Spring container
- 53. .com Global transaction managers in Spring Global transaction manager is TP monitor (transaction processing monitor ) ▷implements the 2-phase commit ▷coordinate multiple XA resources
- 54. .com Global transaction managers in Spring JtaTransactionManager OC4JJtaTransactionManagner WebLogicJtaTransactionManager WebSphereUowTransactionManager
- 55. .com Global transactions with JTA
- 56. .com Spring Transaction Architecture J2EE container deployment
- 57. .com Global transactions with JTA To manage custom global JDBC and JMS transaction see opensource Atomikos or Bitronix
- 58. .com Distributed transaction managers in Spring Distributed transaction managers does not supported from box Outside the scope of the Spring framework.
- 59. .com Benefits of Spring JTA vs EJB
- 60. .com Spring JTA benefits Work with ▷JTA transactions ▷JDBC ▷JPA ▷Hibernate ▷JDO ▷JMS
- 61. .com Spring JTA benefits AOP declarative transaction management
- 62. .com Spring JTA benefits Programmatic transaction management
- 63. .com Spring JTA benefits Offers declarative rollback rules
- 64. .com Spring JTA benefits Customize transactional behavior ▷insert custom behavior in the case of transaction rollback ▷add arbitrary advice ▷rollback the transaction automatically on an application exception
- 65. .com Spring JTA benefits Do not depends from Application Server
- 66. .com Spring JTA benefits No needs transaction-related JNDI lookups
- 68. .com Declarative definition has logic
- 69. .com Different behavior for diff Tx Managers @Transactional(readOnly = true, propagation=Propagation.REQUIRED) public long insertTrade(TradeData trade) throws Exception { //JDBC code... }
- 70. .com Different behavior for diff Tx Managers Not always the same: @Transactional(readOnly = true, propagation=Propagation.REQUIRED) public long insertTrade(TradeData trade) throws Exception { em.persist(trade); return trade.getTradeId(); }
- 71. .com Be aware of Propagation behavior @Transactional(readOnly = true, propagation=Propagation.SUPPORT) public long insertTrade(TradeData trade) throws Exception { //JDBC code... } Allows to write data
- 72. .com Be aware of Propagation behavior @Transactional(readOnly = true) public TradeData getTrade(long tradeId) throws Exception { return em.find(TradeData.class, tradeId); } Will use Propagation.REQUIRED Do you really need transaction for reading?
- 73. .com Be aware of Propagation behavior How about @Transactional(readOnly = true, propagation=Propagation.SUPPORTS) public TradeData getTrade(long tradeId) throws Exception { return em.find(TradeData.class, tradeId); }
- 74. .com Be aware of Propagation behavior Or even no transaction public TradeData getTrade(long tradeId) throws Exception { return em.find(TradeData.class, tradeId);
- 75. .com Be aware of Propagation behavior @Transactional(propagation=Propagation.REQUIRES_NEW) public long insertTrade(TradeData trade) throws Exception {...} @Transactional(propagation=Propagation.REQUIRES_NEW) public void updateAcct(TradeData trade) throws Exception {...} Do you really need always new Transaction?
- 76. .com Rollback behavior @Transactional(propagation=Propagation.REQUIRED) public TradeData placeTrade(TradeData trade) throws Exception { try { insertTrade(trade); updateAcct(trade); return trade; } catch (Exception up) { //log the error throw up; } Will transaction Rollback in case of throw Exception?
- 77. .com Rollback behavior @Transactional(propagation= Propagation.REQUIRED, rollbackFor=Exception.class) public TradeData placeTrade(TradeData trade) throws Exception { try { insertTrade(trade); updateAcct(trade); return trade; } catch (Exception up) { //log the error throw up; } }
- 78. .com Transaction isolation @Transactional(propagation= Propagation.REQUIRED, Isolation = Isolation.REPEATABLE_READ) public long insertTrade(TradeData trade) throws Exception { //JDBC or JPA code... } Will isolation always be changed?
- 79. Thanks! Any questions? You can find me at: becomejavasenior@gmail.com .com
Notes de l'éditeur
- The value attribute of the @Transactional annotation is not mandatory. If not mentionned Spring will look by default for any bean declared in the context with the name “transactionManager” (defaultConvention). https://doanduyhai.wordpress.com/2011/11/20/spring-transactional-explained/
- https://doanduyhai.wordpress.com/2011/11/20/spring-transactional-explained/
- First Spring retrieves the transaction attributes (line 12, 13 & 14) Then it gets the transaction manager from the Spring context and transaction attributes (line 17) A transaction is created by the underlying entity manager (line 26) The target method is invoked (line 33) After returning from the method invocation, the transaction is committed (line 45)
- Point J : doGetTransaction() first Spring tries to look in the TransactionSynchronizationManager ThreadLocal map to see if there is an existing entity manager using the entity manager factory as search key (lines 17 & 18) The entity manager factory was injected into the Jpa transaction manager in the Spring XML definition. If this is not done explicitely, Spring will do the job for you during initialization of the transaction manager by looking for a bean named “entityManagerFactory” (default name by convention) in the context. If an entity manager is found in the ThreadLocal map, Spring wraps it around an EntityManagerHolderobject with a boolean flag isNew = false since this entity manager has been created before hand somewhere in the code. (line 26) Otherwise the EntityManagerHolder of the JpaTransactionObject will be null Spring also retrieves the dataSource declared for this transaction manager and stores it in the JpaTransactionObject (line 46)
- (looking for a bean named “entityManagerFactory” ) Point J : doGetTransaction() first Spring tries to look in the TransactionSynchronizationManager ThreadLocal map to see if there is an existing entity manager using the entity manager factory as search key (lines 17 & 18) The entity manager factory was injected into the Jpa transaction manager in the Spring XML definition. If this is not done explicitely, Spring will do the job for you during initialization of the transaction manager by looking for a bean named “entityManagerFactory” (default name by convention) in the context. If an entity manager is found in the ThreadLocal map, Spring wraps it around an EntityManagerHolderobject with a boolean flag isNew = false since this entity manager has been created before hand somewhere in the code. (line 26) Otherwise the EntityManagerHolder of the JpaTransactionObject will be null Spring also retrieves the dataSource declared for this transaction manager and stores it in the JpaTransactionObject (line 46)
- Point J : doGetTransaction() first Spring tries to look in the TransactionSynchronizationManager ThreadLocal map to see if there is an existing entity manager using the entity manager factory as search key (lines 17 & 18) The entity manager factory was injected into the Jpa transaction manager in the Spring XML definition. If this is not done explicitely, Spring will do the job for you during initialization of the transaction manager by looking for a bean named “entityManagerFactory” (default name by convention) in the context. If an entity manager is found in the ThreadLocal map, Spring wraps it around an EntityManagerHolderobject with a boolean flag isNew = false since this entity manager has been created before hand somewhere in the code. (line 26) Otherwise the EntityManagerHolder of the JpaTransactionObject will be null Spring also retrieves the dataSource declared for this transaction manager and stores it in the JpaTransactionObject (line 46)
- Point J : doGetTransaction() first Spring tries to look in the TransactionSynchronizationManager ThreadLocal map to see if there is an existing entity manager using the entity manager factory as search key (lines 17 & 18) The entity manager factory was injected into the Jpa transaction manager in the Spring XML definition. If this is not done explicitely, Spring will do the job for you during initialization of the transaction manager by looking for a bean named “entityManagerFactory” (default name by convention) in the context. If an entity manager is found in the ThreadLocal map, Spring wraps it around an EntityManagerHolderobject with a boolean flag isNew = false since this entity manager has been created before hand somewhere in the code. (line 26) Otherwise the EntityManagerHolder of the JpaTransactionObject will be null Spring also retrieves the dataSource declared for this transaction manager and stores it in the JpaTransactionObject (line 46)
- Point J : doGetTransaction() first Spring tries to look in the TransactionSynchronizationManager ThreadLocal map to see if there is an existing entity manager using the entity manager factory as search key (lines 17 & 18) The entity manager factory was injected into the Jpa transaction manager in the Spring XML definition. If this is not done explicitely, Spring will do the job for you during initialization of the transaction manager by looking for a bean named “entityManagerFactory” (default name by convention) in the context. If an entity manager is found in the ThreadLocal map, Spring wraps it around an EntityManagerHolderobject with a boolean flag isNew = false since this entity manager has been created before hand somewhere in the code. (line 26) Otherwise the EntityManagerHolder of the JpaTransactionObject will be null Spring also retrieves the dataSource declared for this transaction manager and stores it in the JpaTransactionObject (line 46)
- The X/Open XA standard describes a standardized interface for integrating resources with a transaction manager. If you want to manage a transaction that includes more than one resource, it is essential that the participating resources support the XA standard. Resources that support the XA standard expose a special object, the XA switch, which enables transaction managers (or TP monitors) to take control of their transactions. The XA standard supports both the 1-phase commit protocol and the 2-phase commit protocol. https://access.redhat.com/documentation/en-US/Fuse_ESB/4.3.1/html/EIP_Transactions_Guide/files/TxnIntro-BasicConcepts.html Support for the XA standard In order for a resource to participate in a transaction involving multiple resources, it needs to support the X/Open XA standard. You also need to check whether the resource's implementation of the XA standard is subject to any special restrictions. For example, some implementations of the XA standard are restricted to a single database connection (which implies that only one thread at a time can process a transaction involving that resource). Strictly speaking, the XA standard is not the only approach you can use to support multiple resources, but it is the most practical one. The alternative typically involves writing tedious (and critical) custom code to implement the algorithms normally provided by an XA switch.
- The X/Open XA standard describes a standardized interface for integrating resources with a transaction manager. If you want to manage a transaction that includes more than one resource, it is essential that the participating resources support the XA standard. Resources that support the XA standard expose a special object, the XA switch, which enables transaction managers (or TP monitors) to take control of their transactions. The XA standard supports both the 1-phase commit protocol and the 2-phase commit protocol. https://access.redhat.com/documentation/en-US/Fuse_ESB/4.3.1/html/EIP_Transactions_Guide/files/TxnIntro-BasicConcepts.html 2-phase commit - This is an advanced feature, not supported by all transaction managers. http://samolisov.blogspot.com/2011/02/xa-jta-javase-spring-atomikos.html#p2
- Managing single or multiple resources For transactions involving a single resource, the transaction manager built into the resource can generally be used. For transactions involvingmultiple resources, however, it is necessary to use an external transaction manager or a transaction processing (TP) monitor. In this case, the resources must be integrated with the transaction manager by registering their XA switches. There is also an important difference between the types of algorithm that are used for committing single-resource systems and multiple-resource systems, as follows: 1-phase commit—suitable for single-resource systems, this protocol commits a transaction in a single step. 2-phase commit—suitable for multiple-resource systems, this protocol commits a transaction in two steps. Including multiple resources in a transaction introduces an extra element of risk: there is the danger that a system failure might occur after some, but not all, of the resources have been committed. This would leave the system in an inconsistent state. The 2-phase commit protocol is designed to eliminate this risk, ensuring that the system can always be restored to a consistent state after it is restarted.
- The X/Open XA standard describes a standardized interface for integrating resources with a transaction manager. If you want to manage a transaction that includes more than one resource, it is essential that the participating resources support the XA standard. Resources that support the XA standard expose a special object, the XA switch, which enables transaction managers (or TP monitors) to take control of their transactions. The XA standard supports both the 1-phase commit protocol and the 2-phase commit protocol. https://access.redhat.com/documentation/en-US/Fuse_ESB/4.3.1/html/EIP_Transactions_Guide/files/TxnIntro-BasicConcepts.html
- To understand transaction processing, it is crucial to appreciate the basic relationship between transactions and threads: transactions are thread-specific. That is, when a transaction is started, it is attached to a specific thread (technically, a transaction context object is created and associated with the current thread). From this point on (until the transaction ends), all of the activity in the thread occurs within this transaction scope. Conversely, activity in any other thread does not fall within this transaction's scope (although it might fall within the scope of some other transaction). From this, we can draw a few simple conclusions: An application can process multiple transactions simultaneously—as long as each of the transactions are created in separate threads. Beware of creating subthreads within a transaction—if you are in the middle of a transaction and you create a new pool of threads (for example, by calling the threads() DSL command), the new threads are not in the scope of the original transaction. Beware of processing steps that implicitly create new threads—for the same reason given in the preceding point. Transaction scopes do not usually extend across route segments—that is, if one route segment ends with to(JoinEndpoint) and another route segment starts with from(JoinEndpoint), these route segments typically do not belong to the same transaction. There are exceptions, however (see Breaking a route into fragments). Note Some advanced transaction manager implementations give you the freedom to detach and attach transaction contexts to and from threads at will. For example, this makes it possible to move a transaction context from one thread to another thread. In some cases it is also possible to attach a single transaction context to multiple threads.
- A transaction context is an object that encapsulates the information needed to keep track of a transaction. The format of a transaction context depends entirely on the relevant transaction manager implementation. At a minimum, the transaction context contains a unique transaction identifier.
- The following features determine the quality of service of a transaction manager: Support for suspend/resume and attach/detach. -Some transaction managers support advanced capabilities for manipulating the associations between a transaction context and application threads Support for multiple resources. Distributed transactions. Transaction monitoring. Recovery from failure. Support for multiple resources A key differentiator for transaction managers is the ability to support multiple resources. This normally entails support for the XA standard, where the transaction manager provides a way for resources to register their XA switches. Note Strictly speaking, the XA standard is not the only approach you can use to support multiple resources, but it is the most practical one. The alternative typically involves writing tedious (and critical) custom code to implement the algorithms normally provided by an XA switch. Support for suspend/resume and attach/detach Some transaction managers support advanced capabilities for manipulating the associations between a transaction context and application threads, as follows: Suspend/resume current transaction—enables you to suspend temporarily the current transaction context, while the application does some non-transactional work in the current thread. Attach/detach transaction context—enables you to move a transaction context from one thread to another or to extend a transaction scope to include multiple threads. Distributed transactions Some transaction managers have the capability to manage transactions whose scope includes multiple nodes in a distributed system (where the transaction context is propagated from node to node using special protocols such as WS-AtomicTransactions or CORBA OTS). Transaction monitoring Advanced transaction managers typically provide visual tools to monitor the status of pending transactions. This kind of tool is particularly useful after a system failure, where it can help to identify and resolve transactions that were left in an uncertain state (heuristic exceptions). Recovery from failure There are significant variations amongst transaction managers with respect to their robustness in the event of a system failure (crash). The key strategy that transaction managers use is to write data to a persistent log before performing each step of a transaction. In the event of a failure, the data in the log can be used to recover the transaction. Some transaction managers implement this strategy more carefully than others. For example, a high-end transaction manager would typically duplicate the persistent transaction log and allow each of the logs to be stored on separate host machines.
- The responsibilities of the transaction manager are as follows: Demarcation—starting and ending transactions using begin, commit, and rollback methods. Managing the transaction context—a transaction context contains the information that a transaction manager needs to keep track of a transaction. The transaction manager is responsible for creating transaction contexts and attaching them to the current thread. Coordinating the transaction across multiple resources—enterprise-level transaction managers typically have the capability to coordinate a transaction across multiple resources. This feature requires the 2-phase commit protocol and resources must be registered and managed using the XA protocol (see X/Open XA standard). This is an advanced feature, not supported by all transaction managers. Recovery from failure—transaction managers are responsible for ensuring that resources are not left in an inconsistent state, if there is a system failure and the application crashes. In some cases, manual intervention might be required to restore the system to a consistent state.
- Local transaction managers A local transaction manager is a transaction manager that can coordinate transactions over a single resource only. In this case, the implementation of the transaction manager is typically embedded in the resource itself and the Spring transaction manager is just a thin wrapper around this built-in transaction manager. For example, the Oracle database has a built-in transaction manager that supports demarcation operations (using SQL operations, BEGIN, COMMIT, ROLLBACK, or using a native Oracle API) and various levels of transaction isolation. Control over the Oracle transaction manager can be exported through JDBC, which is how Spring is able to wrap this transaction manager. It is important to understand what constitutes a resource, in this context. For example, if you are using a JMS product, the JMS resource is the single running instance of the JMS product, not the individual queues and topics. Moreover, sometimes, what appears to be multiple resources might actually be a single resource, if the same underlying resource is accessed in different ways. For example, your application might access a relational database both directly (through JDBC) and indirectly (through an object-relational mapping tool like Hibernate). In this case, the same underlying transaction manager is involved, so it should be possible to enrol both of these code fragments in the same transaction. Note It cannot be guaranteed that this will work in every case. Although it is possible in principle, some detail in design of the Spring framework or other wrapper layers might prevent it from working in practice. Of course, it is possible for an application to have many different local transaction managers working independently of each other. For example, you could have one route that manipulates JMS queues and topics, where the JMS endpoints reference a JMS transaction manager. Another route could access a relational database through JDBC. But you could not combine JDBC and JMS access in the same route and have them both participate in the same transaction. https://access.redhat.com/documentation/en-US/Fuse_ESB/4.3.1/html/EIP_Transactions_Guide/files/TxnManagers-WhatIs.html
- Local transaction managers A local transaction manager is a transaction manager that can coordinate transactions over a single resource only. In this case, the implementation of the transaction manager is typically embedded in the resource itself and the Spring transaction manager is just a thin wrapper around this built-in transaction manager. For example, the Oracle database has a built-in transaction manager that supports demarcation operations (using SQL operations, BEGIN, COMMIT, ROLLBACK, or using a native Oracle API) and various levels of transaction isolation. Control over the Oracle transaction manager can be exported through JDBC, which is how Spring is able to wrap this transaction manager.
- http://activemq.apache.org/how-do-transactions-work.html Message Broker handle transactions over Sesssion The Spring transaction manager is only a facade to the actual resource local or JTA transaction managers.
- Standalone Spring container In the standalone deployment model, the Spring container is provides access to persistent data sources and is responsible for managing the transactions associated with those data sources. A notable limitation of the standalone model is that the Spring container can support only local transaction managers, which means that only one data source (resource) at a time can participate in a transaction. Data source Spring supports a variety of different wrapper APIs for accessing persistent storage. For example, to access a database through JDBC, Spring provides the SimpleDriverDataSource class to represent the database instance and the JdbcTemplate class to provide access to the database using SQL. Wrappers are also provided for other kinds of persistent resource, such as JMS, Hibernate, and so on. The Spring data sources are designed to be compatible with the local transaction manager classes.
- Global transaction managers A global transaction manager is a transaction manager that can coordinate transactions over multiple resources. In this case, you cannot rely on the transaction manager built into the resource itself. Instead, you require an external system, sometimes called a transaction processing monitor (TP monitor), that is capable of coordinating transactions across different resources. The following are the prerequisites for global transactions: Global transaction manager or TP monitor—an external transaction system that implements the 2-phase commit protocol for coordinating multiple XA resources. Resources that support the XA standard—in order to participate in a 2-phase commit, resources must support the X/Open XA standard. In practice, this means that the resource is capable of exporting an XA switch object, which gives complete control of transactions to the external TP monitor. Tip The Spring framework does not by itself provide a TP monitor to manage global transactions. It does, however, provide support for integrating with a J2EE TP monitor (where the integration is implemented by the JtaTransactionManager class). Hence, if you deploy your application into a J2EE container that has full transaction support, you can support multiple resources in Spring by accessing the J2EE transaction system.
- Transaction Types Local transactions are easy to manage, and if all operations in your application need to interact with just one transactional resource (such as a JDBC transaction), using local transactions will be sufficient. However, if you are not using an application framework such as Spring, you have a lot of transaction management code to write, and if in the future the scope of the transaction needs to be extended across multiple transactional resources, you have to drop the local transaction management code and rewrite it to use global transactions. In the Java world, global transactions were implemented with the Java Transaction API (JTA). In this scenario, a JTA-compatible transaction manager connects to multiple transactional resources via respective resource managers, which are capable of communicating with the transaction manager over the XA protocol (an open standard defining distributed transactions), and the 2 Phase Commit (2PC) mechanism was used to ensure that all backend datasources were updated or rolled back altogether. If either of the backend resources fails, the entire transaction will roll back, and hence the updates to other resources will be rolled back too. Figure 13-1 shows a high-level view of global transactions with JTA. http://what-when-how.com/Tutorial/SpringFramework3/SpringFramework300456.html
- J2EE container deployment In the J2EE deployment model, the Spring container is nested inside a J2EE application server. The advantage of this deployment model is that the Spring container can leverage the transaction management capabilities of the J2EE container. In particular, the Spring container can now access global transactions, which means that multiple resources can participate in a single transaction. XA resources In a J2EE deployment, the persistent resources should be integrated directly with J2EE. In other words, you do not use Spring data sources in this case. Moreover, in order to enable global transactions, you register each resource's XA interface with the JTA transaction manager in the J2EE environment. JTA transaction manager The Java Transaction API (JTA) and the Java Transaction Service define respectively the API and the implementation of a transaction manager for the J2EE platform. A full implementation of the JTA transaction manager can potentially provide enterprise-level transaction features, including support for global transactions, XA resources, and (in some cases) distributed transactions.
- distributed transactions - interaction of multiple transaction managers in different computers Usually, a server connects directly to the resources involved in a transaction. In a distributed system, however, it is occasionally necessary to connect to resources that are exposed only indirectly, through a Web service or through a CORBA IDL interface. In this case, you require a TP monitor that is capable of supporting distributed transactions. Several standards are available that describe how to support transactions for various distributed protocols—for example, the WS-AtomicTransactions specification for Web services and the CORBA Object Transaction Service (OTS) specification for CORBA applications. Note Distributed transaction managers lie outside the scope of Apache Camel and the Spring framework. If you require support for distributed transactions, you could take a look at a suitable commercial product, such as Artix (for Web services) or Orbix (for CORBA). For distributed transactions, each computer has a local transaction manager. When a transaction does work at multiple computers, the transaction managers interact with other transaction managers via either a superior or subordinate relationship. These relationships are relevant only for a particular transaction.
- distributed transactions - interaction of multiple transaction managers in different computers Usually, a server connects directly to the resources involved in a transaction. In a distributed system, however, it is occasionally necessary to connect to resources that are exposed only indirectly, through a Web service or through a CORBA IDL interface. In this case, you require a TP monitor that is capable of supporting distributed transactions. Several standards are available that describe how to support transactions for various distributed protocols—for example, the WS-AtomicTransactions specification for Web services and the CORBA Object Transaction Service (OTS) specification for CORBA applications. Note Distributed transaction managers lie outside the scope of Apache Camel and the Spring framework. If you require support for distributed transactions, you could take a look at a suitable commercial product, such as Artix (for Web services) or Orbix (for CORBA). For distributed transactions, each computer has a local transaction manager. When a transaction does work at multiple computers, the transaction managers interact with other transaction managers via either a superior or subordinate relationship. These relationships are relevant only for a particular transaction.
- Про глабальный уровень транзакций во всей БД Про уровень изоляци у DataSource Уровень изоляци в connection The JPA transaction manager can take one DataSource only, so it can only issue resource local transactions. In such scenarios, Spring transaction manager is able to override the default DataSource isolation level https://dzone.com/articles/beginners-guide-transaction