org.springframework.transaction.PlatformTransactionManager implementation for a single JDBC
javax.sql.DataSource . This class is
capable of working in any environment with any JDBC driver, as long as the setup
uses a JDBC 2.0 Standard Extensions / JDBC 3.0 javax.sql.DataSource
as its Connection factory mechanism. Binds a JDBC Connection from the specified
DataSource to the current thread, potentially allowing for one thread-bound
Connection per DataSource.
Note: The DataSource that this transaction manager operates on needs
to return independent Connections. The Connections may come from a pool
(the typical case), but the DataSource must not return thread-scoped /
request-scoped Connections or the like. This transaction manager will
associate Connections with thread-bound transactions itself, according
to the specified propagation behavior. It assumes that a separate,
independent Connection can be obtained even during an ongoing transaction.
Application code is required to retrieve the JDBC Connection via
DataSourceUtils.getConnection(DataSource) instead of a standard
J2EE-style
DataSource.getConnection call. Spring classes such as
org.springframework.jdbc.core.JdbcTemplate use this strategy implicitly.
If not used in combination with this transaction manager, the
DataSourceUtils lookup strategy behaves exactly like the native
DataSource lookup; it can thus be used in a portable fashion.
Alternatively, you can allow application code to work with the standard
J2EE-style lookup pattern
DataSource.getConnection , for example for
legacy code that is not aware of Spring at all. In that case, define a
TransactionAwareDataSourceProxy for your target DataSource, and pass
that proxy DataSource to your DAOs, which will automatically participate in
Spring-managed transactions when accessing it.
Supports custom isolation levels, and timeouts which get applied as
appropriate JDBC statement timeouts. To support the latter, application code
must either use
org.springframework.jdbc.core.JdbcTemplate , call
DataSourceUtils.applyTransactionTimeout for each created JDBC Statement,
or go through a
TransactionAwareDataSourceProxy which will create
timeout-aware JDBC Connections and Statements automatically.
Consider defining a
LazyConnectionDataSourceProxy for your target
DataSource, pointing both this transaction manager and your DAOs to it.
This will lead to optimized handling of "empty" transactions, i.e. of transactions
without any JDBC statements executed. A LazyConnectionDataSourceProxy will not fetch
an actual JDBC Connection from the target DataSource until a Statement gets executed,
lazily applying the specified transaction settings to the target Connection.
On JDBC 3.0, this transaction manager supports nested transactions via the
JDBC 3.0
java.sql.Savepoint mechanism. The
DataSourceTransactionManager.setNestedTransactionAllowed "nestedTransactionAllowed" flag defaults
to "true", since nested transactions will work without restrictions on JDBC
drivers that support savepoints (such as the Oracle JDBC driver).
This transaction manager can be used as a replacement for the
org.springframework.transaction.jta.JtaTransactionManager in the single
resource case, as it does not require a container that supports JTA, typically
in combination with a locally defined JDBC DataSource (e.g. a Jakarta Commons
DBCP connection pool). Switching between this local strategy and a JTA
environment is just a matter of configuration!
author:
Juergen Hoeller
since:
02.05.2003
See Also: DataSourceTransactionManager.setNestedTransactionAllowed
See Also: java.sql.Savepoint
See Also: DataSourceUtils.getConnection(javax.sql.DataSource)
See Also: DataSourceUtils.applyTransactionTimeout
See Also: DataSourceUtils.releaseConnection
See Also: TransactionAwareDataSourceProxy
See Also: LazyConnectionDataSourceProxy
See Also: org.springframework.jdbc.core.JdbcTemplate | 