-->
These old forums are deprecated now and set to read-only. We are waiting for you on our new forums!
More modern, Discourse-based and with GitHub/Google/Twitter authentication built-in.

All times are UTC - 5 hours [ DST ]



Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 2 posts ] 
Author Message
 Post subject: Using Session API within doWork of AFTER_STATEMENT release
PostPosted: Tue Nov 28, 2017 11:37 pm 
Newbie

Joined: Thu May 22, 2008 9:48 am
Posts: 13
For the curious, this is a reporting module that uses JDBC, but we are bridging back to Hibernate in specific places.

I have raw JDBC done within a Session.doWork. Inside the doWork, a Session.get is called while operating on a ResultSet. Because of Weblogic's platform transaction manager's default release mode of aggressive (AFTER_STATEMENT), the Session.get results in the release of the Connection by the Session. Which means that I have open ResultSets that are then closed, and the subsequent ResultSet.next (or any access for that matter) throw an exception.

Code:
session.doWork( new Work() {
  public void execute(Connection connection) throws SQLException {
    ...//brevity
    ResultSet rs = pStmt.executeQuery();
    while (rs.next()) { // Exception here on 2nd loop b/c of the 1st iteration's Session.get
      ...//do some work
      Entity ent = session.get(Entity.class, someId);
      ...//do some more
    }
    ...//close up JDBC resources
  }
});

So after the Session.get is called, the next ResultSet.next fails with an exception (already closed). Does Hibernate have anywhere in the API to change a Session's release mode without affecting the entire SessionFactory? I know that adding the following to persistence.xml resolves my issue, but I'm not about to make a change like this for an isolated case:

Code:
<property name="hibernate.connection.release_mode" value="after_transaction"/>

Any ideas? Any more info needed?


Top
 Profile  
 
 Post subject: Re: Using Session API within doWork of AFTER_STATEMENT release
PostPosted: Wed Nov 29, 2017 2:29 am 
Hibernate Team
Hibernate Team

Joined: Thu Sep 11, 2014 2:50 am
Posts: 1628
Location: Romania
Quote:
I know that adding the following to persistence.xml resolves my issue, but I'm not about to make a change like this for an isolated case:


Actually, if WebLogic works fine with AFTER_TRANSACTION, you are better off using that instead of AFTER_STATEMENT.

As for your issue, closing the Connection means returning the Connection to the XA pool. However, the XA pool can't assign the released Connection since your transaction is still not committed or rolled back. That's how JTA Transaction Managers works.

If this is an issue, it must be either the WebLogic or the way the DataSource is configured in WebLogic.

Now, back to your code:

Code:
session.doWork( new Work() {
  public void execute(Connection connection) throws SQLException {
    ...//brevity
    ResultSet rs = pStmt.executeQuery();
    while (rs.next()) { // Exception here on 2nd loop b/c of the 1st iteration's Session.get
      ...//do some work
      Entity ent = session.get(Entity.class, someId);
      ...//do some more
    }
    ...//close up JDBC resources
  }
});   


The reason you are inside a doWork block is to operate on the JDBC Connection, so why do you call the Session?
Your code looks like you are doing an application-level Nested-Loop joining algorithm.

So, you can split those in two. Do the JDBC doWork and return a list of DTOs or whatever you need. Do the processing of DTO + Hibernate calls afterward, outside of the doWork block.


Top
 Profile  
 
Display posts from previous:  Sort by  
Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 2 posts ] 

All times are UTC - 5 hours [ DST ]


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
© Copyright 2014, Red Hat Inc. All rights reserved. JBoss and Hibernate are registered trademarks and servicemarks of Red Hat, Inc.