Spring Framework
  1. Spring Framework
  2. SPR-9028

HibernateInterceptor variant for Hibernate 4

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Complete
    • Affects Version/s: 3.1 GA
    • Fix Version/s: 4.0.2
    • Component/s: Core
    • Labels:
    • Last commented by a User:
      false

      Description

      When using the HibernateInterceptor with Hibernate4, org.springframework.orm.hibernate4.HibernateTransactionManager and org.springframework.orm.hibernate4.LocalSessionFactoryBean I'm getting a signature error which I don't really understand. I added a comment to one of the other issues regarding this, here's the stack trace

      Caused by: java.lang.NoSuchMethodError: org.hibernate.SessionFactory.openSession()Lorg/hibernate/classic/Session;
      at org.springframework.orm.hibernate3.SessionFactoryUtils.doGetSession(SessionFactoryUtils.java:322)
      at org.springframework.orm.hibernate3.SessionFactoryUtils.getSession(SessionFactoryUtils.java:233)
      at org.springframework.orm.hibernate3.HibernateInterceptor.getSession(HibernateInterceptor.java:145)
      at org.springframework.orm.hibernate3.HibernateInterceptor.invoke(HibernateInterceptor.java:90)
      at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
      at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:202)
      at $Proxy44.getAll(Unknown Source)

        Issue Links

          Activity

          Hide
          Juergen Hoeller added a comment -

          Thanks for your feedback so far, guys.

          Raymond, Pawel,

          Could you also use HibernateTemplate, since we're shipping a variant of that as of 4.0.1 now? That is, wrap your Hibernate access in a HibernateCallback and operate on the Session there?

          Or is the reason why you're using HibernateInterceptor primarily the transparent enabling of SessionFactory.getCurrentSession(), with a strong preference of that API style? In that case, could you wrap your data access operations in a HibernateTransactionManager transaction, triggered by @Transactional or programmatic use of a TransactionTemplate?

          Juergen

          Show
          Juergen Hoeller added a comment - Thanks for your feedback so far, guys. Raymond, Pawel, Could you also use HibernateTemplate, since we're shipping a variant of that as of 4.0.1 now? That is, wrap your Hibernate access in a HibernateCallback and operate on the Session there? Or is the reason why you're using HibernateInterceptor primarily the transparent enabling of SessionFactory.getCurrentSession(), with a strong preference of that API style? In that case, could you wrap your data access operations in a HibernateTransactionManager transaction, triggered by @Transactional or programmatic use of a TransactionTemplate? Juergen
          Hide
          Pawel Omelko added a comment -

          It's not that simple to wrap quartz/rmi executed method with HibernateCallback. There is many access from different daos, which expect to have current session.

          Using @Transactional on those (quartz/rmi invoked) method it's not the best idea for existing code. It could cause long db transaction and even some dead locks.

          I can't understand why don't you just give us this HibernateInterceptor. Why not http threads are worst that http?

          Going this way we don't need OpenSessionInView interceptor also, but we already have one for hibernate4

          Did I convinced you?

          Show
          Pawel Omelko added a comment - It's not that simple to wrap quartz/rmi executed method with HibernateCallback. There is many access from different daos, which expect to have current session. Using @Transactional on those (quartz/rmi invoked) method it's not the best idea for existing code. It could cause long db transaction and even some dead locks. I can't understand why don't you just give us this HibernateInterceptor. Why not http threads are worst that http? Going this way we don't need OpenSessionInView interceptor also, but we already have one for hibernate4 Did I convinced you?
          Hide
          Juergen Hoeller added a comment -

          Pawel,

          Thanks for the elaboration. This is exactly why I'm reaching out here: I'd like to better understand where HibernateInterceptor is still useful in 2014, in particular for migrations from Hibernate 3 to Hibernate 4.

          As for transactions, as long as you're only reading, there shouldn't be any locking involved. FWIW, the Hibernate team strongly recommends transactions for any kind of Hibernate Session access, which is a key reason why we've been stronger in our enforcement there as well.

          As for OpenSessionInViewInterceptor, this is a slightly different case since it's less advisable to wrap the MVC view rendering phase in a connection-binding resource transaction, with potentially blocking response I/O involved on HTTP access at the same time.

          That said, I am leaning towards inclusion of some kind of HibernateInterceptor still. It's more about how much functionality it would have, and whether such a class would be marked as deprecated right from the beginning, suggesting alternative approaches instead.

          Juergen

          Show
          Juergen Hoeller added a comment - Pawel, Thanks for the elaboration. This is exactly why I'm reaching out here: I'd like to better understand where HibernateInterceptor is still useful in 2014, in particular for migrations from Hibernate 3 to Hibernate 4. As for transactions, as long as you're only reading, there shouldn't be any locking involved. FWIW, the Hibernate team strongly recommends transactions for any kind of Hibernate Session access, which is a key reason why we've been stronger in our enforcement there as well. As for OpenSessionInViewInterceptor, this is a slightly different case since it's less advisable to wrap the MVC view rendering phase in a connection-binding resource transaction, with potentially blocking response I/O involved on HTTP access at the same time. That said, I am leaning towards inclusion of some kind of HibernateInterceptor still. It's more about how much functionality it would have, and whether such a class would be marked as deprecated right from the beginning, suggesting alternative approaches instead. Juergen
          Hide
          Juergen Hoeller added a comment -

          Actually, we might turn it into a non-deprecated OpenSessionInterceptor or the like in orm.hibernate4.support, next to OpenSessionInViewInterceptor and OpenSessionInViewFilter. Such a focused interceptor implementation would only do Session binding, i.e. no flushing and no exception translation, designed for use at non-web boundaries as you outlined.

          Juergen

          Show
          Juergen Hoeller added a comment - Actually, we might turn it into a non-deprecated OpenSessionInterceptor or the like in orm.hibernate4.support, next to OpenSessionInViewInterceptor and OpenSessionInViewFilter. Such a focused interceptor implementation would only do Session binding, i.e. no flushing and no exception translation, designed for use at non-web boundaries as you outlined. Juergen
          Hide
          Juergen Hoeller added a comment -

          I've added a streamlined OpenSessionInterceptor to orm.hibernate4.support, and also mirrored it in orm.hibernate3.support as a migration help from the outdated HibernateInterceptor there. To be available in the next 4.0.2 snapshot.

          Juergen

          Show
          Juergen Hoeller added a comment - I've added a streamlined OpenSessionInterceptor to orm.hibernate4.support, and also mirrored it in orm.hibernate3.support as a migration help from the outdated HibernateInterceptor there. To be available in the next 4.0.2 snapshot. Juergen

            People

            • Assignee:
              Juergen Hoeller
              Reporter:
              Per Edlund
              Last updater:
              Phil Webb
            • Votes:
              10 Vote for this issue
              Watchers:
              18 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:
                Days since last comment:
                11 weeks ago