Objectives: 4.1 Why use Transactions?
A transaction is an abstraction that is used to group together a series of operations.
The term used to describe whether the operations succeed together or not at all is called atomicity.
A transaction that meets all of the following requirements is said to be an ACID transaction:
Not using transactions can result in: partial failures (inconsistent data), dirty reads, lost updates
One of the most compelling reasons to use the Spring Framework is the comprehensive transaction support.
The consistent abstraction for transaction management offers the following benefits:
No application server is needed if you want have declarative transactions (via EJB).
Allows you to choose when to scale up to a full-blown application server.
Traditionally, J2EE developers have had two choices for transaction management: global or local transactions.
Objectives: 4.5 Spring Transaction Management
Notion of a transaction strategy (PlatformTransactionManager interface)
Easily stubbed or mocked.
Throw unchecked exceptions.
The TransactionDefinition interface specifies:
Non-J2EE Transaction Manager
J2EE Transaction Manager
If the DataSource is managed by the JEE container it should be non-transactional as the Spring Framework, rather than the JEE container, will manage transactions.
Hibernate Transaction Manager
The preferred approach is to use Spring's highest level persistence integration APIs: JdbcTemplate, HibernateTemplate, etc
At a lower level exist classes such as DataSourceUtils (for JDBC), SessionFactoryUtils (for Hibernate).
At the very lowest level exists the TransactionAwareDataSourceProxy class.
This is a proxy for a target DataSource, which wraps the target DataSource to add awareness of Spring-managed transactions.
Objectives: 4.4 Declarative Transactions
Made possible with Spring AOP.
EJB CMT vs Spring Transaction Management
Both allow you to specify transaction behavior (or lack of it) down to individual method level.
Spring Transaction Management has the following:
Declarative transaction support are
that this support is enabled via AOP proxies.
Transactional advice is driven by metadata (currently XML- or annotation-based).
The combination of AOP with transactional metadata yields an AOP proxy that uses a TransactionInterceptor in conjunction with an appropriate PlatformTransactionManager implementation to drive transactions around method invocations.
You can omit the 'transaction-manager' attribute if the bean name of the PlatformTransactionManager is "transactionManager".
The <aop:config/> definition ensures that the transactional advice defined by the 'txAdvice' bean actually executes.
The recommended way to indicate to the Spring Framework's transaction infrastructure that a transaction's work is to be rolled back is to throw an Exception from code that is currently executing in the context of a transaction.
By default, only unchecked exceptions will cause the transaction to be rolled back.
Rollback can be indicated programmatically (using TransactionStatus#setRollbackOnly()) .
The method name(s) with which the transaction attributes
are to be associated. The wildcard (*) character can be used to
associate the same transaction attribute settings with a number
of methods; for example,
||No||REQUIRED||The transaction propagation behavior|
||No||DEFAULT||The transaction isolation level|
||No||-1||The transaction timeout value (in seconds)|
||No||false||Is this transaction read-only?|
Transaction configuration via annotations.
@Transactional annotation should only be applied to methods with public visibility.
<tx:annotation-driven/> only looks for @Transactional on beans in the same application context it is defined in.
The name of transaction manager to use.
The default mode "proxy" will process annotated beans to be proxied using Spring's AOP framework. The alternative mode "aspectj" will instead weave the affected classes with Spring's AspectJ transaction aspect.
Applies to proxy mode only. Controls what type
of transactional proxies are created for classes annotated
Defines the order of the transaction advice that will be applied to
beans annotated with
||optional propagation setting|
||optional isolation level|
||boolean||read/write vs. read-only transaction|
||int (in seconds granularity)||the transaction timeout|
||an array of
||an optional array of exception classes which must cause rollback|
||an array of
||an optional array of names of exception classes that must cause rollback|
||an array of
||an optional array of exception classes that must not cause rollback.|
||an array of
||an optional array of names of exception classes that must not cause rollback|
Objectives: 4.6 Transaction Propagation
Each such logical transaction scope can individually decide on rollback-only status, with
an outer transaction scope being logically independent from the inner transaction scope.
If an inner transaction scopes sets the rollback-only marker, an UnexpectedRollbackException will be thrown (as the outer transaction scope would be unaware of the rollback).
Completely independent transaction are used for each affected
Create a new transaction, suspend the current transaction if one exists.
A single physical transaction with multiple savepoints is used (typically mapped to JDBC savepoints)
Callback approach that frees the application code from having to do the boilerplate acquisition and release of transactional resources, and results in code that is intention driven.
Implement either TransactionCallback() or TransactionCallbackWithoutResult().
Instances of the TransactionTemplate class are threadsafe, but maintain configuration state (like isolation level, etc)
The org.springframework.transaction.PlatformTransactionManager can be used directly to manage Transaction management your transaction.
Declarative transaction management keeps transaction management out of business logic.