1

I am attempting to upgrade our code base from Hibernate 3.6 to 4.0 (just as a first step into getting us more up to date). I am hitting an issue where a COMMIT is not being issued even though we are calling the commit() after making sure the transaction is isActive().

When running some queries successfully against the Postgres database, I see this in the Postgres logs:

2014-12-30 20:09:39 CST LOG:  execute <unnamed>: SET extra_float_digits=3
2014-12-30 20:09:39 CST LOG:  execute S_1: BEGIN
2014-12-30 20:09:39 CST LOG:  execute <unnamed>: -- This script........

Notice the BEGIN there, and then here's an example of the simple commit call:

    if (sf.getCurrentSession().getTransaction().isActive()) {
        sf.getCurrentSession().getTransaction().commit();
    }

I have debugged down into AbstractTransactionImpl and am looking at a Jdbc4Connection commit() method, and see that the actual COMMIT call is being skipped.....but I don't know why. Here's the if statement that this is failing on (it is in AbstractJdbc2Connection).

if (protoConnection.getTransactionState() != ProtocolConnection.TRANSACTION_IDLE)
    executeTransactionCommand(commitQuery);

So, apparently our transactionstate is == ProtocolConnection.TRANSACTION_IDLE. However, I'm not entirely sure what that entails, and why are we getting this issue when the transaction says it isActive()?

NOTE: this same exact code worked for us on Hibernate 3.6.

Thanks.

UPDATE: I debugged further, and it looks like there are many ProtocoalConnectionImpl objects being constructed, does that indicate a problem on our software side that is doing something it shouldn't? Like does that indicate that we're opening connections that are just hanging around? Thanks for any more insight.

JamesD
  • 607
  • 1
  • 8
  • 22

1 Answers1

0

So it turns out I was doing something incorrect (surprise). There's a good reason that the TransactionState was showing as TRANSACTION_IDLE and not issuing a commit.

I had seen in multiple places on the internetz where people were getting access to a JDBC connection in the new Hibernate 4.x land by getting access to the underlying ConnectionProvider (sort of like this: https://stackoverflow.com/a/21271019/115694).

However, the problem with doing that is that you are getting a BRAND NEW connection....instead of the connection associated with the current session. This is a pretty big no-no, or at least for us it was.

You do have to in fact do what the person says in this answer: https://stackoverflow.com/a/3526626/115694

Basically, you MUST use the Work API.

Community
  • 1
  • 1
JamesD
  • 607
  • 1
  • 8
  • 22