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 {@link DataSourceUtils#getConnection(DataSource)} instead of a standardJ2EE-style {@link DataSource#getConnection()} call. Spring classes such as{@link org.springframework.jdbc.core.JdbcTemplate} use this strategy implicitly.If not used in combination with this transaction manager, the {@link DataSourceUtils} lookup strategy behaves exactly like the nativeDataSource 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 {@link DataSource#getConnection()}, for example for legacy code that is not aware of Spring at all. In that case, define a {@link TransactionAwareDataSourceProxy} for your target DataSource, and passthat 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 {@link org.springframework.jdbc.core.JdbcTemplate}, call {@link DataSourceUtils#applyTransactionTimeout} for each created JDBC Statement,or go through a {@link TransactionAwareDataSourceProxy} which will createtimeout-aware JDBC Connections and Statements automatically.
Consider defining a {@link LazyConnectionDataSourceProxy} for your targetDataSource, 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 {@link java.sql.Savepoint} mechanism. The{@link #setNestedTransactionAllowed "nestedTransactionAllowed"} flag defaultsto "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 {@link org.springframework.transaction.jta.JtaTransactionManager} in the singleresource 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 #setNestedTransactionAllowed @see java.sql.Savepoint @see DataSourceUtils#getConnection(javax.sql.DataSource) @see DataSourceUtils#applyTransactionTimeout @see DataSourceUtils#releaseConnection @see TransactionAwareDataSourceProxy @see LazyConnectionDataSourceProxy @see org.springframework.jdbc.core.JdbcTemplate
| |