BeginTransaction and commit slow down read throughput

huseyinsikici · **Joined:** Tue Nov 02, 2004 2:43 am **Posts:** 5

Hi, I am using Hibernate 3.0, and have two read-only objects which map to tables with 11,000 and 100,000 rows respectively. I am not currently using the latest HibernateUtil mentioned in the Manning book, I am opening session through my util, but starting the transaction using the Session object. I beginTransaction() and commit() for all my Hibernate operations, read or write, doesn't matter.

The problem is, when I load test my application, the performance is ok only if I have as many concurrent Threads as there are # of connections in my connection pool.

Any more threads cause my app to lock up.

When I get rid of beginTransaction and commit() the app runs very fast.

Should I not use beginTransaction and commit for reads, or is there a Hibernate trick to help me out.

Thanks,

----------------
Hibernate version: 3.0

public class HibernateSession {

static HibernateSession instance = null;
static SessionFactory sf = null;
static Configuration cfg = null;

public static HibernateSession instance() throws Exception{
if (instance == null) {
instance = new HibernateSession();
cfg = new Configuration();
cfg.addClass(Cell.class);
cfg.addClass(com.oksijen.smlc.util.Configuration.class);
cfg.addClass(CellNeighbor.class);
sf = cfg.buildSessionFactory();
}
return instance;
}

public Session getSession() throws Exception {
Session s = sf.openSession();
return s;
}

public org.hibernate.Session getNewSession() throws Exception {
Session s = sf.openSession();
return s;
}

public SessionFactory getSessionFactory() {
return sf;
}

[b]Name and version of the database you are using: MySQL 4.0

christian · **Posted:** Tue Apr 19, 2005 11:25 am

I don't know what your real problem is (certainly not using transaction demarcation), but the code you posted has a race condition on the non-threadsafe Session object. You might want to read up chapters 4, 5 and 8 in that sequence in HiA.

christian · **Posted:** Tue Apr 19, 2005 11:26 am

Actually I'm wrong and got confused by "HibernateSession".

anthony · **Posted:** Tue Apr 19, 2005 12:44 pm

can you show us javacode (where you play with begin and commit)?

huseyinsikici · **Joined:** Tue Nov 02, 2004 2:43 am **Posts:** 5

Sure, here is the code:

Code:

Session s = null;
Transaction t = null;
      
 try {
      s = HibernateSession.instance().getSessionFactory().openSession();
      t = s.beginTransaction();

     Cell c = (Cell) s.load(Cell.class, new Integer(cellId));
     ...
     ...

} finally {
     t.commit();
     s.close();
}

The # of threads I can let loose on this guy is the same as the # of conns in my connection pool. I use C3P0. I have specified read-only caching for the Cell object. [/code][/quote]

anthony · **Posted:** Wed Apr 20, 2005 3:05 am

what can you see in the log? is there something changing?

huseyinsikici · **Joined:** Tue Nov 02, 2004 2:43 am **Posts:** 5

What kind of change? I am not sure the answer to this problem is "look at the log" category... This really has to do how Hibernate was implemented. A guru should be able to say if Hibernate, as an implementation choice, was written to do something with the db connection and database when beginTransaction is issued. Therefore, the reasoning might continue, that max # of threads accessing an app can never the # of db connections.

OR, Hibernate, through a setting, can recognize that EVEN IF a beginTransaction was issued, but there were no writes inside that txn, manages NOT to access the database. Then # of threads can exceed the # of connections in the pool, once this setting/call/whatever is used.

We do currently have a workaround for this problem: We simply do not call beginTransaction if there is only reads performed on read-only cached objects. But I would really like to use one standard way of calling Hibernate, so it's easier on the developers to remember.

Cheers,

steve · **Posted:** Wed Apr 20, 2005 10:43 am

Hibernate does nothing with the Connection on beginning a transaction.

More than likely what you are running into is that the session is flushing at transaction commit, with a large number of entities associated with the session. And a setting does exist to govern this; it is called FlushMode. If you know you will never modify objects retreived through a certain session, then set that sessions flush mode to FlushMode.NEVER (and do not manually flush the session).

martin_groenhof · **Joined:** Mon Aug 16, 2010 12:32 pm **Posts:** 12

I have this problem that my session.flush() or transaction.commit() are getting slower and slower, the app races through the 1st 500k rows at about 15Mbit than it slows to a cralw below 1Mbit and stalling, when I comment out the session flushing and commiting than the performance of read is constant, why would the commit take progresively more time

when I skip the 1st 1000000 rows, the performance over the 1st 50-100k rows is good but than falls of a cliff, what is wrong with session commit ?

Code:

      h.setItems(itms);
      if (!onlyTest) {
          session.persist(h); // < ----------------- save this object in a batch 
      }
       }
            // session.flush()
       tx.commit();
   } catch (final Exception ex) {
       tx.rollback();
       logger.error(ex.getMessage());
   } finally {
       if (session != null && session.isConnected()) {
      session.clear();
      session.close();
       }
   }