Global transactions
Global transactions enable you to work with multiple transactional resources, typically relational databases and message queues. The application server manages global transactions through the JTA, which is a cumbersome API to use (partly due to its exception model). Furthmore, a JTA UserTransaction normally needs to be sourced from JNDI,meaning that you also need to use JNDI in order to use JTA. Obviously the use of global transactions would limit any potential reusr of application code, as JTA is normally only available in an application server environment.
Previously, the preferred way to use global transactions was via EJM CMT(Container Managed Transaction):CMT is a form of declarative transaction management (as distinguished from programmatic transaction management).EJB CMT removes the need for transaction-related JNDI lookups, although of cource the use of EJB itself necessitates the use of JNDI. It removes most but not all of the need to write Java code to control transactions. The significant downside is that CMT is tied to JTA and an application server environment. Also,it is only available if one chooses to implements business logic in EJBs, or at least behind a transactional EJB facade. The negatives of EJB in general are so great that this is not an attractive proposition, especially ine the face of compelling alternatives for declarative transaction management.
Local transactions
Local transactions are resource-specific, such as a transaction associated with a JDBC connnection. Local transactions may be easier to use, but have significant disadvantages: they cannot work access multiple transactional resources. For example, code that manages transactions using a JDBC connection cannot run within a global JTA transaction. Because the application server is not involved in transaction management, it cannot help ensure correctness across multiple resources. (It is worth nothing that most application use a single transaction resource.) Another downside is that local transactions are invasive to the programming model.
Spring Framework's consistent programming model
Spring resolves the disadvantage of global and local transactions. It anables appplication developers to use a consistent programming model in any environment. You write your code once, and it can benefit from different transaction managements strategies in different environments. The Spring Framework provides bothdeclarative and programmatic transaction management. Moost users pre decllarative transaction management, which is recommended in most cases.
With programmatic transaction management, developers work with the Spring Framework transaction abstraction, which can run over any underlying transaction infrastructure. With the preferred declarative model, developers typically write little or no code related to transaction management, and hence do not depend on the Spring Framework transaction API, or any other transaction API.
Note
If you use JTA, then your transaction manager definition will look the same regardless of what data access technology you use, be jt JDBC, Hibernate JPA or any other supported technology. This is due to the face that JTA transactions are global transactions, which can enlist any transactional resource.
注：
invasive：侵入的
underlying: 底层的