[Springframework-developer] Reworked transaction managers and Hibernate/JDO support

[<jue...@we...>]

I've committed a significant refactoring of our transaction manager =
implementations: AbstractPlatformTransactionManager has a =
"cleanupAfterCompletion" template method now, which has formerly been =
handled by subclasses. It also cares about exception handling on commit =
failure now, offering a "rollbackOnCommitFailure" property with the =
default being "false". The latter is intended for misbehaving JDBC =
drivers or JDO implementations; normally, there shouldn't be a need to =
set it to true.
=20
HibernateTemplate and HibernateTransactionManager have a =
"jdbcExceptionTranslator" property now, supporting a =
SQLExceptionTranslator that kicks in when callback code throws an =
SQLException or HibernateJDBCException. Default is =
SQLStateSQLExceptionTranslator because of the ease of setup. The main =
rationale is to throw proper DataIntegrityViolationExceptions on =
corresponding Hibernate-rethrown SQLExceptions - Steve from the =
Hibernate team made be aware of the issue.
=20
JdoTemplate and JdoInterceptor have a common base class JdoAccessor now, =
similar to HibernateAccessor, and support for a JdoDialect. The latter =
represents a strategy for retrieving the underlying JDBC connection and =
for eagerly flushing a PersistenceManager, to be implemented for =
specific JDO products. It also provides a hook for specific translation =
of JDOExceptions to Spring's DataAccessException hierarchy. This allows =
for richer support of JDO in Spring, like exporting transactions to JDBC =
access code and eager flushing to make the latter aware of changes.
=20
Juergen