3 Replies Latest reply on Apr 21, 2006 3:57 AM by colin lewis

    JBoss 4.0.3SP1 and Hibernate3

    colin lewis Newbie

      The documentation for JBoss 4.0.3 states that when using CMT the hibernate session should be looked up using the HibernateContext class. The class that is shipped deprecates that method and states that sessionFactory.getCurrentSession() should be used. However when I use this method I get an error stating that there is no JTA transaction. I'm guessing because of some discrepency between what hibernate and jboss think is the transaction manager. Any clues?

      I general I am a bit bemused the latest changes to hibernate, previously the method for looking up a session factory and dealing with transaction was the same regardless of whether you were taking part in a CMT or not making any DAO's portable. The latest changes seem to break that. The documentation seems a bit light here too.

        • 1. Re: JBoss 4.0.3SP1 and Hibernate3
          colin lewis Newbie

          Further investigation reveals that where I am calling openSession(), and therefore not taking part in a JTA transation) but a JTA transaction exists calls to tx.commit and session.close are being ignored as if I am in a transaction.

          Is this a bug, or am I missing something?

          • 2. Re: JBoss 4.0.3SP1 and Hibernate3
            Jeffrey Williams Newbie

            I am having the same issue did you ever find a solution to this problem?

            • 3. Re: JBoss 4.0.3SP1 and Hibernate3
              colin lewis Newbie

              In short yes, what we had to do is remove any transaction demarcation code, and any calls to session.close(), in dao methods that were called inside a container transaction. Persistence was then correctly managed by the container.

              The only exception to this where you get hold of the underlying connection by calling session.connection() in this case you must close the connection.

              Be careful to also remove the catching of HibernateExeption as Hibernate 3 has made this exception unchecked and rely on this to orchestrate a rollback, (it's a standard feature of J2EE containers that unchecked exceptions cause any current transaction to be rolled back).

              The documention for this makes it sound like all of this is optional, it is not. It should be in big red lights in the documentation and the migration guide.