Incremental migration to hibernate from raw JDBC

germania · **Joined:** Tue Jun 27, 2006 11:01 pm **Posts:** 4

Hi all,

First off, I absolutely think Hibernate is a godsend. Thank you to all the developers who have made it possible.

I've been developing and maintaining a servlet based webapp for about 5 years now, and have decided that moving to hibernate will significantly improve performance and maintainability into the future. I have things working, but I wanted to get feedback on whether what I'm doing is totally unacceptable, or if it makes some sense. Basically there's a single contact point for retrieving JDBC connections in the application, which I have changed to this (consider it pseudo-code, thread synchronization and such have been thoroughly tested):

Code:

class WhatEver {

    Connection getConnection() {
        SessionFactory factory = ........;
        Session session = factory.getCurrentSession();
        session.beginTransaction();
        
        Connection con = session.connection();
        return con;
    }

    void returnConnection(Connection con) {
          factory.getCurrentSession().close();
    }

}

I have this in hibernate.cfg.xml, so as long as a connection is only used by one thread (which I've spent a significant amount of effort verifying is the case), I think it should make sense...

Code:

<property name="current_session_context_class">thread</property>

The code would be called as so:

Code:

Connection con = whatever.getConnection();
try {
  PreparedStatement ps = con.prepareStatement("SELECT * FROM MEH;");
  ResultSet rs = ps.executeQuery();
   blahblah(rs);
} finally {
  rs.close();
  ps.close();
  whatever.returnConnection(con);
}

Is there a preferred way of using raw JDBC connections for the pieces of my application I cannot afford the time to port immediately? Does this make sense?

Thanks much for any feedback, I look forward to a great relationship with Hibernate :)

Ben.

tenwit · **Joined:** Thu Dec 23, 2004 9:08 pm **Posts:** 2008

What you've done is fine. A proper connection pool would be better, and hibernate does handle user-supplied connections: they've very handy for gradual migration from plain old JDBC. So you could give one connection to hibernate, and use others for your old code; or you could use the same connection for both, doing what you've done here.

Of course plenty of testing will be required, as it's quite easy to run into write locks or even deadlocks if using a pool; and if you're going with one connection per thread, it's easy to miss a con.close() in an old piece of code, suddenly cutting hibernate off at the feet. But they actual coding isn't difficult, you've already got it there.

germania · **Joined:** Tue Jun 27, 2006 11:01 pm **Posts:** 4

Thank you for the reply, tenwit.

I had actually been using a manually upgraded version of jdbcpool (it never supported jdbc2), so my thought was that switching to a hibernate-managed c3p0 pool would more or less take over the same role (am I mistaken as to what c3p0 does?). Bottom line, there was always a connection pool in place, and associated debugging to make sure that all deadlocks and such were ironed out.

Should I be then lead to understand that this, in hibernate.cfg.xml, does not create a connection pool for me (alongside the code I already have demonstrated)?

Code:

    <property name="c3p0.min_size">3</property>
    <property name="c3p0.max_size">5</property>
    <property name="c3p0.timeout">1800</property>

Thanks,

Ben.

tenwit · **Joined:** Thu Dec 23, 2004 9:08 pm **Posts:** 2008

That will create your pool. I don't think that you need any more than that: I presume that if your legacy JDBC-using code requests a connection from c3p0, it'll come from the same pool, and that should accomplish everything you need.

germania · **Joined:** Tue Jun 27, 2006 11:01 pm **Posts:** 4

Perfect. Thank you so much.

Ben.