Proxy for a target DataSource, fetching actual JDBC Connections lazily,
i.e. not until first creation of a Statement. Connection initialization
properties like auto-commit mode, transaction isolation and read-only mode
will be kept and applied to the actual JDBC Connection as soon as an
actual Connection is fetched (if ever). Consequently, commit and rollback
calls will be ignored if no Statements have been created.
This DataSource proxy allows to avoid fetching JDBC Connections from
a pool unless actually necessary. JDBC transaction control can happen
without fetching a Connection from the pool or communicating with the
database; this will be done lazily on first creation of a JDBC Statement.
If you configure both a LazyConnectionDataSourceProxy and a
TransactionAwareDataSourceProxy, make sure that the latter is the outermost
DataSource. In such a scenario, data access code will talk to the
transaction-aware DataSource, which will in turn work with the
LazyConnectionDataSourceProxy.
Lazy fetching of physical JDBC Connections is particularly beneficial
in a generic transaction demarcation environment. It allows you to demarcate
transactions on all methods that could potentially perform data access,
without paying a performance penalty if no actual data access happens.
This DataSource proxy gives you behavior analogous to JTA and a
transactional JNDI DataSource (as provided by the J2EE server), even
with a local transaction strategy like DataSourceTransactionManager or
HibernateTransactionManager. It does not add value with Spring's
JtaTransactionManager as transaction strategy.
Lazy fetching of JDBC Connections is also recommended for read-only
operations with Hibernate, in particular if the chances of resolving the
result in the second-level cache are high. This avoids the need to
communicate with the database at all for such read-only operations.
You will get the same effect with non-transactional reads, but lazy fetching
of JDBC Connections allows you to still perform reads in transactions.
NOTE: This DataSource proxy needs to return wrapped Connections to
handle lazy fetching of an actual JDBC Connection. Therefore, the returned
Connections cannot be cast to a native JDBC Connection type like OracleConnection,
or to a connection pool implementation type. Use a corresponding
NativeJdbcExtractor to retrieve the native JDBC Connection.
author: Juergen Hoeller since: 1.1.4 See Also: ConnectionProxy See Also: DataSourceTransactionManager See Also: org.springframework.orm.hibernate.HibernateTransactionManager See Also: org.springframework.jdbc.support.nativejdbc.NativeJdbcExtractor |