I recently upgraded the version of Hibernate and C3P0 in my application from
Hibernate-3.2.7.ga.jar and c3p0-0.9.1.2.jar

TO

hibernate-core-3.3.2.GA.jar hibernate-c3p0-3.3.2.GA.jar

There was no good reason for me to do this, it simply seemed appropriate to try a more recent version and tests did not reveal any problem.

Everything appeared to work fine in testing, but there is some sort of subtle problem in production. Things will work fine, and then after maybe about an hour the connectivity breaks down. The first sign comes from my connection pool

2011-03-10 09:02:06,967 [dbpool/26] ERROR util.JDBCExceptionReporter - Communications link failure

The last packet successfully received from the server was 1,292,776 milliseconds ago. The last packet sent successfully to the server was 36 milliseconds ago.
2011-03-10 09:02:06,968 [dbpool/26] ERROR dao.CallStatsDao - HibernateException
org.hibernate.exception.JDBCConnectionException: could not execute query
at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:97)
at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:66)
at org.hibernate.loader.Loader.doList(Loader.java:2235)
at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2129)
at org.hibernate.loader.Loader.list(Loader.java:2124)
at org.hibernate.loader.criteria.CriteriaLoader.list(CriteriaLoader.java:118)
at org.hibernate.impl.SessionImpl.list(SessionImpl.java:1597)
at org.hibernate.impl.CriteriaImpl.list(CriteriaImpl.java:306)
at org.hibernate.impl.CriteriaImpl.uniqueResult(CriteriaImpl.java:328)
...

Caused by: com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure

Once this happens no database connections work.

Interestingly, perhaps, there are three application servers, one of which is on the same network as the database server, the other two not. The one that is on the same network does not experience this problem.

These are my c3p0 settings. They are unchanged from the previous version's.



Unless someone can offer an explanation about what might be going on here, my immediate approach is going to be to revert hibernate and c3p0 to the previous version. I can't think of anything else.

Hi,
enable some more verbose logging and verify that you're actually using C3P0, some time ago some properties changed.

Well, you may be onto something.

I bumped my log4j logger for com.mchange to DEBUG (it had been WARN) and I don't see anything. And I know my logging configuration is correct because occasionally I would see error output from this logger when there were errors.

Can you suggest some "acid test" of something that should definitely appear in the log if Hibernate has properly engaged c3p0?

INFO-level logging (log4j.logger.org.hibernate=info) should be enough to get a lot of information at SessionFactory creation/initialization. Look for something like this:



followed by more lines of C3P0 information. If Hibernate is using a different connection provider, try setting the following property in your hibernate.properties:

Okay, I now definitely establish that the version running
Hibernate-3.2.7.ga.jar and c3p0-0.9.1.2.jar
is using c3p0:


while the version running
hibernate-core-3.3.2.GA.jar and hibernate-c3p0-3.3.2.GA.jar
is not:



I still don't understand why. There are no errors indicating any kind of failure to load c3p0 in the new version, and as far as I can tell the property mechanism is as I remembered it from a couple years ago. But maybe I don't have the most recent docs?

Aargh! hibernate-c3p0-3.3.2.GA.jar depends on (and Maven correctly includes) c3p0-0.9.1.jar. But this is an OLDER version of c3p0 than my older version of Hibernate was using (c3p0-0.9.1.2.jar). Could that be why I'm having these issues? There are so many versions out there, what should I be using?

In theory, minor versions shouldn't break APIs but only fix bugs.
so the 9.1.2 should work as drop in replacement for a 9.1.0, but I don't know for sure we don't maintain c3p0 ourselves: just try.

Also, often it's not possible to fix bugs without breaking some API or changing some semantics, so I'd say it's a good idea to upgrade from such an old version.

It seems you should upgrade more aggressively:
HHH-4156
or use the property specified on the JIRA description.

Thanks. That's the REAL answer, another property is required now.

As for upgrading more aggressively, my problem is that my bosses think I upgrade too aggressively now.

Lol. it's not that old software automatically is more stable: it's not going to download patches by himself.
I have been a user myself, so please don't see me now as a "seller", but as an experienced user I can tell that you only have three options:
* buy the enterprise support
* always upgrade to latest community version, or follow closely
* follow the development closely and backport all patches you need to the version you're stuck on (and contributing them back)

use JIRA's report functionality, and extract a list of bugfixes from your old version, you'll get enough arguments to choose one of these ;)

So to recap the solution of this specific issue, there was a time when it was possible to successfully configure Hibernate for the use of c3p0 simply by defining several properties with keys of the form

hibernate.c3p0.* as described above.

There was (and is) also another property key
hibernate.connection.provider_class

which could be provided the value "org.hibernate.connection.C3P0ConnectionProvider" (the other properties are still necessary to configure these values) but this definition was not compulsory. The Hibernate configuration engine deduced from the presence of the other properties that you wanted to use C3P0.

With the newer versions of Hibernate, this backdoor mechanism no longer works and that's arguably a good thing. It makes sense to require that you explicitly specify that you want to use C3P0. It's more logical.

However, there is still a lot of older documentation out there that does not mention this including the official Hibernate manual! Had I more vigorously upgraded I might have found this out sooner, but I would no doubt have stubbed my toe on it at some point in time.

For example
http://docs.jboss.org/hibernate/core/3. ... erence.pdf says
(p.32)

This is just not true anymore.

This is in spite of the fact that the use of the hibernate.connection.provider_class property has apparently been mandatory at least since version 3.3. And this has not been changed in the manual for 3.6 either.

sorry I don't agree, your recap is quite misleading.
This was just a bug, and was fixed since 3.5.4 as reported on the link I provided you.

So as it just works as before now, there's no need to change any documentation, it was not intended to be removed.

So what I meant when saying to "upgrade more aggressively", I meant to jump to 3.6.2, where it just works without the need for the additional property.

I don't see how you can say that. If you want to call it a bug that Hibernate used to guess your intention to use c3p0 by the presence of C3P0 tuning parameters in the configuration without requiring the configuration parameter that says "use c3P0 connection providing", I can accept that, as I indicated.

But what I don't accept is the fact that official Hibernate documentation still promotes the notion that Hibernate will intuit the fact that you want to use c3p0 by the presence of tuning parameters. That is not the case. The documentation still reads as though the bug were not fixed and it's incorrect.

Again:



It should read:



Both are required but the documentation has not been updated from the days before the bug was fixed.

There is some unofficial documentation that does it better.

For example: http://blog.hpxn.net/2009/02/05/using-c ... bernate-3/

Here, it is said


This documentation correctly indicates the central importance of the one property that is not even mentioned in the official documentation. Good for them, but there is still plenty of old documentation out there that propounds the old way. The Hibernate documentation, which is supposed to be authoritative, should not be among those.

Hibernate needs to fix the documentation to reflect the new state of the package now that the bug in the code has been fixed.

sorry I didn't explain myself well and got you confused.
There's nothing to fix: the documentation is right, you don't need to set the connection.provider_class with the current hibernate releases. you are using an old unsupported version.
I just double checked it works fine on 3.6.2: explicitly setting the connection.provider_class is not needed, of course it won't do you any harm, so go ahead and use it but stop saying the docs aren't right.

Btw, it's a community project, so in case the docs are wrong you should make a patch and send it: people won't search for the docs on the forum so even in case it's a waste of time to explain this here.

OK, I think I now understand. The bug you are referring to is not the bug I thought you were referring to. I thought you were saying that the old behavior (pre 3.3) was a bug (and I agree with that). But you are actually saying that the old behavior was okay and the change in 3.3 that broke it was the bug, now fixed by reverting back to the pre-3.3 behavior. The only reason I am having this problem is because I upgraded to 3.3 and not to a supported version. 3.5.4 or better.

When I planned this upgrade, I tried to go to the latest version and got into some sort of dependency hell that I no longer remember the details of, so I dialed back to the "baby step" of upgrading to what I could get to work. Probably not the best move but given my current schedules, there's no way around that except the workaround you suggested. Thanks.

I still think the way it worked in 3.3 is more logical, but I understand your need to support the installed base.

I agree as well, but was decided otherwise ;) generally speaking, we try to do "the right thing" with as less possible configuration, sometimes it gets confusing and I agree this is one of them.