|
From: Rod J. <rod...@in...> - 2003-11-06 10:27:10
|
This reminds me: we really need to try to increase the range of our error codes in sql-error-codes.xml and make the SQLStateErrorCodeTranslator more comprehensive. Any volunteers for contributing vendor error codes based on Oracle manuals etc. and SQLState codes based on the relevant SQL standard? Regards, Rod ----- Original Message ----- From: "jürgen höller [werk3AT]" <jue...@we...> To: <spr...@li...> Sent: Wednesday, November 05, 2003 8:35 PM Subject: Re: [Springframework-developer] Reworked transaction managers and Hibernate/JDO support I've just added one more refactoring: I've dissolved ThreadObjectManager and put the resource binding (for JDBC/JDO/Hibernate/etc) into TransactionSynchronizationManager. Additionally, DataSourceUtils and PersistenceManagerFactoryUtils now register transaction synchronizations for JDBC Connections and JDO PersistenceManagers, respectively: This mainly means that you are guaranteed to get the same JDBC Connection or JDO PersistenceManager per DataSource respectively PersistenceManagerFactory in a Spring-managed JTA transaction, just like it already was the case with a Hibernate Session per SessionFactory. You can thus rely on receiving the same JDBC Connection within a JTA transaction instead of having to trust your JTA implementation. Colin, haven't you had concerns about that a while ago? Juergen ________________________________ Von: spr...@li... im Auftrag von jürgen höller [werk3AT] Gesendet: Mi 05.11.2003 10:43 An: spr...@li... Betreff: [Springframework-developer] Reworked transaction managers and Hibernate/JDO support 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. 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. 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. Juergen ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |