I've read here and in the docs that the built in connection pooling is not meant to be used in production. I did some poking around our code and found that we started using this and never switched over to DBCP or c3p0. So we, as idiots, have been using the built in pooling in production.

What exactly are the problems with this? I know that using it with mySql can cause big problems (found that out on a personal non-work project), but we're using MSSQL 2000 and haven't noticed any big, glaring problems yet. So getting us to switch will be a little more difficult unless I know more. ("Whaddya mean switch? It's not broken now.")

Does anyone have any specific comments on hibernate's connection pooling, or can you point me in the right direction so I can figure it out? Thank you.

You may experience leaking connections, etc. The built in pool is not very robust. "Switching" is not that diffucult, really.

Yeah, switching is pretty easy. As far as I can tell, I just have to redo some lines in the configuration files. That's what I did with a personal app, and it's been working fine.

Also, we've been using three classes: HibernateMonitor, HibernateEngine, and HibernateSessionSource, written by Eric Everman and Simon Robins, to take care of hanging db connections. Could it be the case that those are shielding us from the problems with hibernate's built in connection pooling?

In my experience with MS Sql server (using the ms driver and built in connection pool) every now and then I got a "connection reset by peer" error. I suppose this is not the pools fault per se, but when we switched to a JBoss managed Datasource havent had this problem (or any other) in production.

We have not run into this problem yet. But it's good to be aware of such things.

We are using this driver: com.jnetdirect.jsql.JSQLDriver

As I said, we have had no glaring problems yet. I suppose I'm looking for some more subtle problems that maybe we are not seeing but are in existence.