JTATransaction vs UserTransaction (+ flushing)

Tarka · **Joined:** Tue Oct 21, 2003 10:47 pm **Posts:** 10

Hi,

Could somebody explain to me the differences between using JTATransactions and UserTransaction? When is it appropriate to use one over the other? And what is their relationship to net.sf.hibernate.Transaction?

Also, is there a method to cause Hibernate to automatically cause a complete rollback regardless of the transaction strategy? It seems 'wrong' to me to have to flush before the rollback.

Thanks

david · **Posted:** Fri Jan 09, 2004 2:04 am

JTA Transaction is the standard defined by java for transaction management aim toward containers but can be implemented (and user) independently (JTOM as an example). UserTransaction is an interface defined by the same standard for manually controlling a JTA transaction. The net.sf.hibernate.Transaction interface provides a API netural interface for directly and indirectly accessing the transaction manager configured for the session factory. Flush is not always necessary before a rollback it depends on the context. Hibernate uses the unit-of-work pattern so database operations are schedualled but not sent to the datasource need to be flushed to make sure that data is in sync. This is important when using a transaction manager outside of Hibernate knowledge - such a user transactions.

Tarka · **Joined:** Tue Oct 21, 2003 10:47 pm **Posts:** 10

david wrote:

JTA Transaction is the standard defined by java for transaction management aim toward containers but can be implemented (and user) independently (JTOM as an example). UserTransaction is an interface defined by the same standard for manually controlling a JTA transaction. The net.sf.hibernate.Transaction interface provides a API netural interface for directly and indirectly accessing the transaction manager configured for the session factory.

That bit I get. Sorry, my question was a badly worded, I should probably be more specific: The hibernate manual shows several examples of using transactions, sometimes using its built-in Transaction wrapper, sometimes explicitly using JTA UserTransaction instances. However, it's not clear when one should be used over another.

david wrote:

Flush is not always necessary before a rollback it depends on the context. Hibernate uses the unit-of-work pattern so database operations are schedualled but not sent to the datasource need to be flushed to make sure that data is in sync. This is important when using a transaction manager outside of Hibernate knowledge - such a user transactions.

However, even when using Hibernate's transactions it is still necessary to call flush before rollback. Is this intentional, or is it a bug? The manual seems to imply that the rollback should handle the flush if necessary, but that doesn't seem to be the case.

Thanks for the help.

david · **Posted:** Fri Jan 09, 2004 9:37 am

The hibernate wrapper provides some independence from the transaction layer that has been configured, eg, straight JDBC or JTA. It also allows Hibernate to manage things such as flushing the unit-of-work queues since it knows that a commit/rollback is going to occur. It hides some of the details so you don't need to worry about it. Why don't you write two small sample programs and see which works best for you. I would not say there a right way as such. Coding is an Art - see what feels the best and go with it.

Tarka · **Joined:** Tue Oct 21, 2003 10:47 pm **Posts:** 10

david wrote:

The hibernate wrapper provides some independence from the transaction layer that has been configured, eg, straight JDBC or JTA. It also allows Hibernate to manage things such as flushing the unit-of-work queues since it knows that a commit/rollback is going to occur. It hides some of the details so you don't need to worry about it. Why don't you write two small sample programs and see which works best for you. I would not say there a right way as such. Coding is an Art - see what feels the best and go with it.

Well, in the case of the UserTransactions vs Hibernate transactions I've thought about it a bit more (probably should have done that in the first place :) and come to the following conclusion:

When your transactions operate purely within the database domain it is usually better to manage the transactions through Hibernate. However when your transactions involve other actions outside of hibernate (e.g. JMS) you will need to manage them yourself via JTA UserTransaction.

Sound right? Placed here for future reference.

But back to the flush issue. If Hibernate is managing the transactions shouldn't it also manage the interaction of the database and transaction? In other words, this should work:

Code:

                Transaction tx = session.beginTransaction();
                id = (Long) session.save(myObject);
                // Shouldn't need this
                // session.flush();
                tx.rollback();

But it doesn't, I need to put the flush there. Is this a bug? If not, it might be good to put a note in the manual to that effect, as it currently implies that the flush is handled by the transaction.

Cheers,
Steve[/i]

gavin · **Posted:** Fri Jan 09, 2004 11:34 pm

Why on earth would you ever want to flush before rolling back??

How bizarre!

Hibernate flushes before commit.

Tarka · **Joined:** Tue Oct 21, 2003 10:47 pm **Posts:** 10

gavin wrote:

Why on earth would you ever want to flush before rolling back??

How bizarre!

Hibernate flushes before commit.

Because otherwise the rollback doesn't occur, either in the database or in Hibernate's internal state. Take this reasonably complete example:

Code:

        try {

            Simple s = new Simple("FirstObj");
            Simple s2 = new Simple("SecondObj");

            SessionFactory sf = (SessionFactory) new InitialContext().lookup("hibernate/SessionFactory");
            Session session = sf.openSession();

            // First transaction, that we intend to rollback
            Transaction tx = session.beginTransaction();
            id = (Long) session.save(s);

            // No flush, why would we need it?
            //session.flush();
            tx.rollback();

            // Second transaction, that we intend to commit
            Transaction tx2 = session.beginTransaction();
            id = (Long) session.save(s2);
            tx2.commit();

            session.close();

        } catch (Exception e) {
            log.error("HibernateException during Hibernate session");
            fail("HibernateException while looking up Hibernate session");
        }

Without the flush, this results in two objects in the database. The rollback simply doesn't occur. Does this seem wrong to you?

Tarka · **Joined:** Tue Oct 21, 2003 10:47 pm **Posts:** 10

gavin wrote:

Why on earth would you ever want to flush before rolling back??

How bizarre!

Hibernate flushes before commit.

Because otherwise the rollback doesn't occur, either in the database or in Hibernate's internal state. Take this reasonably complete example:

Code:

        try {

            Simple s = new Simple("FirstObj");
            Simple s2 = new Simple("SecondObj");

            SessionFactory sf = (SessionFactory) new InitialContext().lookup("hibernate/SessionFactory");
            Session session = sf.openSession();

            // First transaction, that we intend to rollback
            Transaction tx = session.beginTransaction();
            id = (Long) session.save(s);

            // No flush, why would we need it?
            //session.flush();
            tx.rollback();

            // Second transaction, that we intend to commit
            Transaction tx2 = session.beginTransaction();
            id = (Long) session.save(s2);
            tx2.commit();

            session.close();

        } catch (Exception e) {
            log.error("HibernateException during Hibernate session");
            fail("HibernateException while looking up Hibernate session");
        }

Without the flush, this results in two objects in the database. The rollback simply doesn't occur. Now this may be me, but this seems wrong.

Tarka · **Joined:** Tue Oct 21, 2003 10:47 pm **Posts:** 10

(Double post, so much for transactions :)

gavin · **Posted:** Sat Jan 10, 2004 12:08 am

If you roll back a transaction, you MUST discard the Hibernate session. Hibernate does not (yet) implement object-level rollback because, if enabled by default, it is a performance killer. (It is on the roadmap, but I'm not really aware of anyone who is asking for this feature.)

Tarka · **Joined:** Tue Oct 21, 2003 10:47 pm **Posts:** 10

gavin wrote:

If you roll back a transaction, you MUST discard the Hibernate session. Hibernate does not (yet) implement object-level rollback because, if enabled by default, it is a performance killer. (It is on the roadmap, but I'm not really aware of anyone who is asking for this feature.)

OK, that makes more sense. However it's not clear in the manual that this is required except for on an exception (and there are places where it's implied it is not required, e.g. "a session may span several transactions"). Can I suggest the following at the end of 8.10.2:

If you rollback the transaction you should immediately close and discard the current session to ensure that Hibernate's internal state is consistent.

Thanks both.
Steve

christian · **Posted:** Sat Jan 10, 2004 6:28 am

Added.