Hibernate Books

All times are UTC - 5 hours [ DST ]



Post new topic Reply to topic  [ 3 posts ] 
Author Message
 Post subject: Cursor closed on commit in bulk operation
PostPosted: Thu Apr 20, 2017 5:18 am 
Newbie

Joined: Wed Apr 19, 2017 8:15 am
Posts: 5
Hello,

we have huge amounts of data, that are usually read and updated like this:

Code:
   tx = session.beginTransaction();
   ScrollableResults scroll = session.createQuery("from " + Employee.class.getName())
         .scroll(ScrollMode.FORWARD_ONLY);
   while (scroll.next()) {
      Employee emp = (Employee) scroll.get()[0];
      emp.setFirstName("abc");
      session.update(emp);
      tx.commit();
   }
   scroll.close();


In hibernate versions before 5.2, this was no problem, since cursor queries lived as long a they were not closed
manually. However in hibernate 5.2 this does not work, since all queries are close on commit, resulting in an Excepton in scroll.next():

org.hibernate.exception.GenericJDBCException: could not advance using next()

In older hibernate version there was an option like

ConnectionReleaseMode.ON_CLOSE

so that cursor queries survived the commmit.
But in hibernate 5 the ConnectionReleaseMode.ON_CLOSE does still close the cursor queries.

We probable missed something?


Top
 Profile  
 
 Post subject: Re: Cursor closed on commit in bulk operation
PostPosted: Thu Apr 20, 2017 6:52 am 
Hibernate Team
Hibernate Team

Joined: Thu Sep 11, 2014 2:50 am
Posts: 1227
I don't think your approach is a valid one for the following reasons:

1. There is no need to call session.update. The entity should be already managed by Hibernate, so every change is automatically picked by the dirty checking mechanism and propagated to the DB during flushing.
2. Why do you call commit after every entity modification? The whole point of the write-behind caching mechanism offered by the Hibernate Session is to group multiple entity state transitions into an atomic unit of work. You should batch multiple modifications to reduce the number of database roundtrips.
3. Why do you use Scrolling anyway? In most cases, pagination renders better results than scrolling/streaming.
4. ON_CLOSE is not a correct way to handle the connection release, AFTER_TRANSACTION and AFTER_STATEMENT are much better since a connection should not be kept outside the scope of a transactional context.

Therefore, you should rethink your current data access layer. But there are even more optimizations you can do like statement caching, using subentities to reduce fetching size. If you are interested in this topic, you should definitely read High-Performance Java Persistence.

_________________
If you liked my answer, you are going to love my High-Performance Java Persistence book and my blog as well.


Top
 Profile  
 
 Post subject: Re: Cursor closed on commit in bulk operation
PostPosted: Mon Apr 24, 2017 3:08 am 
Newbie

Joined: Wed Apr 19, 2017 8:15 am
Posts: 5
Thanks for answering me.

1. and 2. Just wanted to keep the example small and simple.

3. and 4. Before I confront our application engineers with such a big change in their application logic,
I like to be certain that there is not a more simple solution.

What strikes me is, that hibernate 5 is different than hibernate < 5 and pure JDBC.
And falling back to JDBC is, what seems to be the only option here:

Open the cursor queries in a JDBC connection and transform the data in hibernate.
That doesnt look nice, but the change in application logic is small.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 3 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.