1

I have read a few posts on this topic: e.g., here and here

In my case, I am certain that all transactions are committed and that all exceptions are handled with a rollback.

Currently, I am building the model layer for a web app (Spring/Hibernate/Postgres). I am using junit to rigorously test as I build. For some reason, on one delete test I repeatedly got the "nested transaction not supported" exception.

Session session=HibernateDAO.getSessionFactory().getCurrentSession();

    try
    {   

        session.getTransaction().begin();

        List<TestUnitType> result = session.createQuery("from TestUnitType").list();



        TestUnitType itemToDelete = result.get(0);


        session.delete(itemToDelete);
        session.getTransaction().commit();

    } catch (Exception e)
    {
        TestSS.getLogger().error(e.toString(), e);

        session.getTransaction().rollback();
        fail(e.toString());
    }

The exception is thrown when calling the transaction prior to the query. The previous method definitely closed the transaction as it is couched in the same syntax as this method (and I carefully debugged).

I resolved the issue by creating a kludge method and using it to get the session:

public static Session resetCurrentSession()
{
    Session oldsession = getSessionFactory().getCurrentSession();
    if(oldsession.isOpen())
    {
        oldsession.close();
    }
    return getSessionFactory().getCurrentSession();
}

All unit tests now run and pass, the data in the database is clean and I see no side effects of my kludge. Nonetheless, I am uncomfortable using a workaround in unit tests. No fix is safe if the programmer does not know the cause of the problem behind it.

can someone advise on the possible cause of the exception?

Community
  • 1
  • 1
Jake
  • 4,322
  • 6
  • 39
  • 83
  • Well I see this as a "is it a Hibernate bug or my bug?" question, and you can guess towards which I lean to. Show the code of the previous method. You can also turn on debug logging for Hibernate, that should show you if you're not finishing transactions. – Kayaman Jul 14 '15 at 05:15
  • the hibernate logging showed nothing untoward except the error.The code for the previous method is exactly the same, except it is a query within the try block. – Jake Jul 14 '15 at 06:08
  • Also, I don't think it's a hibernate "bug," but wonder whether threading issues might be at play here (even though junit is running tests consecutively). My question to the community is whether there are any other causes of this issues other than not properly closing transactions in user code – Jake Jul 14 '15 at 06:12
  • So you had TRACE on for the hibernate package and the log shows all the transactions being closed properly, but the error is thrown? – Kayaman Jul 14 '15 at 06:12
  • fair enough, no, debug. It's late here and the code is about 30 mins from compileable. I'll check tomorrow and get back to you – Jake Jul 14 '15 at 06:27
  • Can't replicate (and did not change transaction code). I am not ruling out human error, but still hold a threading issue as possible. I'll leave this open, if I may, and will report if I find any firm answer. – Jake Jul 14 '15 at 21:48

1 Answers1

0

The answer was junit related, not hibernate related.

It seems that assert statements in junit will exit a method, so if the assert statement is prior to the commit, then the commit does not happen.

This is no doubt a beginner error in junit, but may be of use to other beginners.

Jake
  • 4,322
  • 6
  • 39
  • 83