|
From: Colin S. <col...@ex...> - 2004-09-24 19:08:09
|
Well, at a minimum the JavaDoc for HibernateTemplate where it says it's a programmatic alternative to HibernateInterceptor needs to be clarified to say that the interceptor will always bind a Session regardless of a current transaction, while the template will only do so while in a transaction. Personally, I also believe in doing all data-access within transactions, but there _are_ people who for certain scenarios prefer not to have a transaction. I seem to remember Gavin being against non-transactional access, but Hibernate does work fine that way, and it's certainly a valid mode in JDO, etc. With regards to nested HibernateTemplate calls, it's not as unlikely as it may seem, since code may call other code, and people are using HibernateTemplate for exception wrapping and convenience methods, not just Session management. In the forum thread I mentioned, somebody was complaining (that in a non-transactional situation) they were doing a HibernateTemplate.load() call, and the retuned object itself was unusable as it was a proxy (not a lazy relationship, but the actual object returned). In this case, he's got no programmatic method ensure that a series of contained HibernateTemplate calls are handled withing one thread-bound Session. For my preferred style (always using transactions), there's obviously no issue, but I do think if the HibernateTemple is about resource management (part of it anyways), and that resource (the Session) works outside of a transaction, then it's not very logical to restrict the management (or at least the thread-binding portion) to only happen within a transaction... And probably the same for JDO, etc. Colin jürgen höller [werk3AT] wrote: >Well, HibernateInterceptor is an AOP Interceptor: Its very point is to bind a Hibernate Session to the thread. In other words, it would be completely pointless to not bind a Session there, because the interceptor wouldn't to anything then. > >HibernateTemplate on the other hand is supposed to execute a given HibernateCallback, respectively the internal callbacks for the shortcut methods - nothing else. It is not necessary to bind a Session to the thread for this, therefore HibernateTemplate doesn't do so. > >Nested HibernateTemplate calls would be somewhat strange anyway: A HibernateCallback that in turn delegates to some other class that in turn uses HibernateTemplate again? I don't think that this is really common. Do you have a concrete use case for this? > >Note that JdoTemplate, JdbcTemplate, etc all behave the same in that respect: None of those binds anything to the thread for the duration of its execute methods. Just the special interceptors for Hibernate and JDO do so, mainly for use with JtaTransactionManager. > >In total, I'd like to keep the current behavior. Remember that you're supposed to perform all data access within transactions anyway, so all that talk about non-transactional Sessions is nonsense and useless noise. "There is no such thing as a non-transactional Session." ;-) > >Juergen > > >-----Original Message----- >From: spr...@li... >[mailto:spr...@li...]On Behalf >Of Colin Sampaleanu >Sent: Friday, September 24, 2004 6:59 PM >To: spr...@li... >Subject: [Springframework-developer] Why does HibernateInterceptor bind >Session always, while HibernateTemplate only if there is a tx? > > >Juergen, > >I was poking around in the HibernateInterceptor and HibernateTemplate >code following a forum post, and unless I'm missing something, >HibernateInterceptor (correctly) binds the new Session that is created >to the current thread even if there is no transaction already existing >to synchronize to, but on the other hand, on the execute() call >HibernateTemplate will only bind the Session to the thread if >transaction synchronization is active. Am I missing something? If this >is correct, this does not seem appropriate to me, as HibernateTemplate >should be (and is listed in the JavaDocs) as the programattic equivalent >of HibernateInterceptor, and nested HibernateTemplate calls should >utilize a thread-bound session put there by the outermost one, >regardless of transaction settings, not create a new Session. > >Am I missing something? > >Colin > > |