Menu
▾
▴
springframework-developer
|
From: <jue...@we...> - 2003-05-08 10:18:39
|
Hi transaction fans, I've just changed the approach for mixing Hibernate and plain JDBC = access within one transaction: Using DataSourceTransactionManager = required feeding Hibernate a Spring-looked-up JDBC connection (supported = via HibernateTemplate), and didn't support Hibernate's transactional = caching. I've removed this custom-JDBC-connection-for-Hibernate stuff = completely, both from SessionFactoryUtils and HibernateTemplate. There's a better solution: HibernateTransactionManager is now able to = register Hibernate's JDBC Connection just like = DataSourceTransactionManager does. This means that plain JDBC code = automatically takes part in transactions managed by = HibernateTransactionManager! Of course, the application code has to = stick to the required JDBC connection lookup = (DataSourceUtils.getConnection), just like with = DataSourceTransactionManager. But it doesn't need to be aware of = Hibernate at all! That way, mixing transactional services that can use either Hibernate or = plain JDBC internally is possible without restrictions (i.e. including = transactional caching) - with perfect reusability of the latter in = non-Hibernate environments. Regards, Juergen -----Original Message----- From: j=FCrgen h=F6ller [werk3AT]=20 Sent: Wednesday, May 07, 2003 1:44 PM To: spr...@li... Subject: [Springframework-developer] Hibernate support and DataSource transactions Hi everybody, I've just checked the Hibernate stuff in, including the Hibernate = libraries that are necessary for executing the test suite (not enough = for full usage by applications). It's in com.interface21.orm.hibernate. = Most of it should be pretty self-evident and extensively documented, for = people who already know Hibernate's basics. A special issue is handling a Hibernate SessionFactory: I've provided 2 = classes named LocalSessionFactory and JndiSessionFactory. Being = FactoryBeans, they behave like a Hibernate SessionFactory when used as = bean reference. This allows for setting up a SessionFactory in an = application context, and handing it to = HibernateTemplate/HibernateTransactionManager's "sessionFactory" = property as bean reference (or to any custom services having a = SessionFactory-type property). This way, changing from a locally built = SessionFactory to a JNDI one (when using the J2EE Connector) is just a = matter of configuration. For convenience, = HibernateTemplate/HibernateTransactionManager also provide a property = "sessionFactoryName", for direct JDNI lookup. I've also reworked our DataSourceUtils and our DataSource = implementations (DriverManagerDataSource and = SingleConnectionDataSource), reusing code as far as possible, and = allowing for bean-style configuration. All the DataSource-related stuff = is now in com.interface21.jdbc.datasource, taking some classes from = jdbc.core and jdbc.mock (jdbc.mock doesn't exist anymore). On the = occasion, I've introduced a JndiDataSource class that applies the = FactoryBean setup approach to DataSource (as elaborated above regarding = Hibernate). This allows for setting up a DataSource bean in an = application context, either = DriverManagerDataSource/SingleConnectionDataSource or the JndiDataSource = factory, all of them representing a DataSource when given as bean = reference, e.g. to JdbcTemplate, DataSourceTransactionManager, or = HibernateTemplate. Changing from a JNDI DataSource to a local DataSource = is just a matter of configuration, which is nice for test or standalone = environments. Of course, we still support mock JNDI with our = com.interface21.jndi.mock too. Apropos: There's a DataSourceTransactionManager now, an implementation = of PlatformTransactionManager capable of handling transactions for a = single DataSource. It allows applications that just access a single = database to use high-level transaction demarcation, either via = TransactionTemplate or the AOP transaction interceptor - without = requiring JTA support in the container! HibernateTransactionManager = applies the same approach to a single Hibernate SessionFactory, for = applications that access their single database just via Hibernate, = allowing for Hibernate's transactional caching. If the latter isn't = required, DataSourceTransactionManager can be used with Hibernate too, = with the requirement that the Hibernate Sessions must be fed with a = custom DataSourceUtils-looked-up JDBC connection. HibernateTemplate = conveniently supports this with its dataSource/dataSourceName property. = With this approach, direct JDBC access is supported too, while other = code can leverage Hibernate on the same DataSource - within one = transaction! We're already using that stuff in a new product we're developing at = werk3AT, and are pleased with it so far. Have a look at it, I'm looking = forward to your feedback! Regards, Juergen P.S.: In contrast to standard JTA and thus our JtaTransactionManager, both = DataSourceTransactionManager and HibernateTransactionManager do support = isolation levels! P.P.S.: An obvious follow-up is similar support for JDO: a JdoTemplate, a = JdoTransactionManager for JDO-only access to a single database, a = LocalPersistenceManagerFactory and a JndiPersistenceManagerFactory. I = _might_ look at this myself some time, but I've invested quite a lot of = time on the stuff above, so it would definitely take a while. Any = volunteers? :-) DI J=FCrgen H=F6ller Senior System Architect ______________________________________ werk3ATS - division systementwicklung part of werk3AT internetmedien oeg europaplatz 4 A - 4020 linz t. +43 (0) 732 71 65 29 502 f. +43 (0) 732 71 65 29 3 jue...@we... www.werk3at.com ______________________________________ werk3ATS - WIR ENTWICKELN ERFOLG ------------------------------------------------------- Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara The only event dedicated to issues related to Linux enterprise solutions www.enterpriselinuxforum.com _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Thomas R. <tri...@tr...> - 2003-05-08 16:48:58
|
Jürgen, I think Hibernate/JDO support is great. Looking forward to trying it out. >> P.P.S.: An obvious follow-up is similar support for JDO: a JdoTemplate, a JdoTransactionManager for JDO-only access to a single database, a LocalPersistenceManagerFactory and a JndiPersistenceManagerFactory. I _might_ look at this myself some time, but I've invested quite a lot of time on the stuff above, so it would definitely take a while. Any volunteers? :-) I have been meaning to try JDO for a while. This will give me an excuse to get around to it, but I don't really know how soon. I'll keep you posted. Thomas Risberg |
