[java/jee] Beste JDBC connection pool

[Verwijderd]

Ik vroeg me af welke JDBC connection pool implementatie nou algemeen als de beste wordt beschouwd. Momenteel gebruiken we de bitmechanic pool ( jdbcpool-0.99.jar ), maar deze wordt al jaren en jaren niet meer onderhouden.

Een bekende pool is natuurlijk de jakarta commons DBCP. Deze zit ook standaard bij Tomcat. Hij is echter ook al weer wat ouder. Op zoek naar wat reviews hierover kwam ik op een oude post op theserverside.com, maar daar was men er niet echt super enthousiast over. Helaas stond er dan weer niet welke pool wel goed (of beter) was.

Na nog een beetje doorzoeken zag ik dat de PostgreSQL JDBC driver ook een connection pool bevat, maar de docs zeggen: "In general it is not recommended to use the PostgreSQL™ provided connection pool.".

Wat zijn de ervaringen van mensen hier met de verschillende connection pool in een JEE omgeving? Ik ben specificiek op zoek naar de combinatie Postgresql 7.4 & Tomcat 5.5.

[Nick_S]

Ik maak zelf meestal gebruik van DBPool.

http://homepages.nildram.co.uk/~slink/java/DBPool/

[Verwijderd]

En? Is deze goed vergeleken met DBCP?

Ik zag hem er ook tussen staan op:

http://java-source.net/open-source/connection-pools

Maar ook in deze uitgebreide lijst helaas geen comments over hoe relatief goed deze zijn. Wat ik bijvoorbeeld zoek is een pool die duidelijk aan geeft (door bv log messages) als er stale connections zijn die ge-reaped worden, en dan het liefst nauwkeurig vertellen welke code deze connection aanvroeg.

[Alarmnummer]

Ik gebruik DBCP in een aantal vrij eenvoudige projecten (icm tomcat)&(die niet door extreem veel bezoekers gebruikt worden) en ben tot zover nog geen problemen tegengekomen.

[Verwijderd]

Alarmnummer schreef op vrijdag 14 oktober 2005 @ 17:07:
Ik gebruik DBCP in een aantal vrij eenvoudige projecten (icm tomcat)&(die niet door extreem veel bezoekers gebruikt worden) en ben tot zover nog geen problemen tegengekomen.

Ok, het zal in mijn geval toch wel om een 'aanzienlijk' aantal bezoekers gaan.

[Alarmnummer]

Verwijderd schreef op vrijdag 14 oktober 2005 @ 17:26:
[...]
Ok, het zal in mijn geval toch wel om een 'aanzienlijk' aantal bezoekers gaan.

Daar heb ik met Tomcat icm DBCP geen ervaring mee. Ik ben nog maar vrij kort bezig om Tomcat te gebruiken. Op dit moment is het voornamelijk voor kleinere projecten. Als uiteindelijk de meeste rimpels zijn weggewerkt (lees praktische ervaring opdoen zodat je anderen kunt helpen als er problemen optreden) en als het allemaal prettig werkt, dan gaan we wellicht ook grotere projecten onder Tomcat laten draaien. We draaien op dit moment voornamelijk JBoss maar dat is voor ons meestal overkill (aangezien we geen EJB gebruiken, en verder van Spring/Hibernate gebruik maken).

[ Voor 38% gewijzigd door Alarmnummer op 14-10-2005 17:41 ]

[momania]

Hier zijn nog wat verschillende opties: http://java-source.net/open-source/connection-pools

Voor zover ik weet maakt Hibernate gebruik van C3P0: http://sourceforge.net/projects/c3p0
Misschien is dat dan wel een goeie om naar te kijken

[matthijsln]

Mijn ervaring met de combinatie Tomcat/DBCP/PostgreSQL is dat het het wel irritant is dat wanneer een verbinding wordt verbroken (bijvoorbeeld herstart van de server of netwerk valt even weg) er geen nieuwe verbinding wordt gemaakt en de app een error krijgt. Misschien dat er een simpele instelling is zoals autoReconnect=true net zoals bij MySQL maar die had ik zo even snel niet gevonden.

Verder hoef ik eigenlijk zo weinig mogelijk van een connection pool te merken (ik heb dan ook niet zoveel hits dat ik heel erg op performance moet letten).

[Alarmnummer]

matthijsln schreef op vrijdag 14 oktober 2005 @ 19:50:
Mijn ervaring met de combinatie Tomcat/DBCP/PostgreSQL is dat het het wel irritant is dat wanneer een verbinding wordt verbroken (bijvoorbeeld herstart van de server of netwerk valt even weg) er geen nieuwe verbinding wordt gemaakt en de app een error krijgt. Misschien dat er een simpele instelling is zoals autoReconnect=true net zoals bij MySQL maar die had ik zo even snel niet gevonden.

Dat probleem heb je ook met JBoss (tenminste.. out of the box... ik weet niet of je nog iets aan de settings kunt aanpassen om dit probleem te fixen)

[ Voor 6% gewijzigd door Alarmnummer op 14-10-2005 22:23 ]

[flowerp]

Eigenlijk zou iemand eens een artikel moeten schrijven waarin connection pools vergeleken worden. Ik zou eigenlijk ook wel iets waarmee je makkelijk leaks kunt opsporen. Heb nu al een paar keer gehad dat ik aan de max. van mijn aantal connecties zat en dan wil ik wel graag weten welk stuk code de connectie niet vrijgeeft.

[Verwijderd]

Is er hier niemand die een (grote) java web applicatie draaid met veel bezoekers?

Gebruiken jullie dan een connection pool en zo ja welke?

[MisterData]

In Tomcat heb ik zojuist DBCP aangezet en daar zit een fijne optie in die automatisch verbindingen 'abandoned' als ze langer dan x seconden niet gebruikt worden. Het leuke is dat DBCP ook een stacktrace kan loggen van het laatste gebruik van die verbinding/resultset die abandoned wordt, zodat je precies ziet waar je vergeet een verbinding/resultset te closen

Volgende stukje XML gebruik ik:

XML:

<Context ....>
    <Resource name="..." type="javax.sql.DataSource"
    driverClassName="com.mysql.jdbc.Driver"
    driverName="..."
    url="...?autoReconnect=true"
    username="..."
    password="..." 
    maxIdle="2" 
    maxWait="5000"
    maxActive="4"
    removeAbandoned="true"
    removeAbandonedTimeout="60"
    logAbandoned="true"  <!-- deze dus -->
    />
</Context>

[momania]

Verwijderd schreef op maandag 17 oktober 2005 @ 12:52:
Is er hier niemand die een (grote) java web applicatie draaid met veel bezoekers?

dat wel

Gebruiken jullie dan een connection pool en zo ja welke?

Wij gebruiken eigenlijk altijd een DataSource en laten dus connection pooling over aan de application server. Nog nooit problemen mee gehad eigenlijk,dus vandaar dat verder onderzoek daarin ook niet nodig is

[Verwijderd]

momania schreef op maandag 17 oktober 2005 @ 13:09:
[...]
dat wel

Ok dan!

Wij gebruiken eigenlijk altijd een DataSource en laten dus connection pooling over aan de application server.

Een DataSource hoeft toch niet perse connections te poolen? (het kan natuurlijk wel)
Welke AS gebruiken jullie dan?

[momania]

Verwijderd schreef op maandag 17 oktober 2005 @ 13:21:
[...]
Een DataSource hoeft toch niet perse connections te poolen? (het kan natuurlijk wel)
Welke AS gebruiken jullie dan?

Bij m'n vorige werk WebSphere en op m'n huidige werk JBoss

Met beide nog geen problemen gezien mbt datasources en de connectionpooling
Ja, hooguit dat we bij de datasource settings het aantal connections hoger hadden staan dan de oracle database toe liet

[Alarmnummer]

Je zou misschien nog kunnen kijken naar:
http://sourceforge.net/projects/c3p0

[Verwijderd]

Ik gebruik proxool (http://proxool.sourceforge.net/), en heb daar tot nu toe nog geen problemen mee gehad.

Ik heb ook DBPool gebruikt, maar die heb ik aan moeten passen omdat het niet deed wat ik wilde. En aanpassen was op dat moment sneller dan alles ombouwen.

[Verwijderd]

Alarmnummer schreef op dinsdag 18 oktober 2005 @ 08:30:
Je zou misschien nog kunnen kijken naar:
http://sourceforge.net/projects/c3p0

Ik zag die ook al een paar keer er tussen staan. Voordeel van deze is iniedergeval dat ie recent ge-update is.

Wat ik echter vooral zoek is een beetje vergelijkingen of gebruikerservaringen, omdat het anders weer gewoon zomaar een pool is die ik gebruik zonder dat ik er veel van weet. Het kan natuurlijk ook dat het onzin is om pools te gaan vergelijken, omdat het concept zo simpel is dat elke pool even goed is en dat ik mijn tijd verspil om naar de 'beste' op zoek te gaan.

[Alarmnummer]

Verwijderd schreef op dinsdag 18 oktober 2005 @ 11:33:
[...]


Ik zag die ook al een paar keer er tussen staan. Voordeel van deze is iniedergeval dat ie recent ge-update is.

Wat ik echter vooral zoek is een beetje vergelijkingen of gebruikerservaringen, omdat het anders weer gewoon zomaar een pool is die ik gebruik zonder dat ik er veel van weet. Het kan natuurlijk ook dat het onzin is om pools te gaan vergelijken, omdat het concept zo simpel is dat elke pool even goed is en dat ik mijn tijd verspil om naar de 'beste' op zoek te gaan.

Maar zo`n probleem zal het toch niet zijn om de ene implementatie uit te wisselen voor de andere. Ik zou zeggen: kies er gewoon een, en als dat niet goed werkt, dan kijk je naar een ander.

[bloody]

matthijsln schreef op vrijdag 14 oktober 2005 @ 19:50:
Mijn ervaring met de combinatie Tomcat/DBCP/PostgreSQL is dat het het wel irritant is dat wanneer een verbinding wordt verbroken (bijvoorbeeld herstart van de server of netwerk valt even weg) er geen nieuwe verbinding wordt gemaakt en de app een error krijgt. Misschien dat er een simpele instelling is zoals autoReconnect=true net zoals bij MySQL maar die had ik zo even snel niet gevonden.

Neem het volgende in je postgres-ds.xml op in je datasource element:

code:

    <check-valid-connection-sql>select now()</check-valid-connection-sql>

[matthijsln]

bloody schreef op dinsdag 18 oktober 2005 @ 15:48:
[...]
Neem het volgende in je postgres-ds.xml op in je datasource element:

code:

    <check-valid-connection-sql>select now()</check-valid-connection-sql>

Als ik in de context van mn webapp in het Resource element voor de JNDI database resource een validationQuery opneem heb ik het probleem met PostgreSQL niet meer. Met de combinatie jTDS/MSSQL blijft het probleem echter nog steeds

[Stephan Oudmaijer]

c3p0 is een veel gebruikte. Icm met o.a. Hibernate... zie: http://java-source.net/open-source/connection-pools/c3p0

[bloody]

matthijsln schreef op dinsdag 18 oktober 2005 @ 22:06:
[...]
Als ik in de context van mn webapp in het Resource element voor de JNDI database resource een validationQuery opneem heb ik het probleem met PostgreSQL niet meer. Met de combinatie jTDS/MSSQL blijft het probleem echter nog steeds

Ik heb die "select now()" er in gezet omdat dat een geldige en lichte postgresql statement is.
Ik heb geen idee of die ook voor mssql geldig is! Wellicht moet je hier een andere select gebruiken (bv "select 1")

[matthijsln]

bloody schreef op woensdag 19 oktober 2005 @ 08:50:
[...]
Ik heb die "select now()" er in gezet omdat dat een geldige en lichte postgresql statement is.
Ik heb geen idee of die ook voor mssql geldig is! Wellicht moet je hier een andere select gebruiken (bv "select 1")

Ik heb inderdaad "select 1" en een select uit een echte tabel geprobeerd (naast een heleboel andere instellingen), maar dit hielp allemaal niet... Na een stop en start van MSSQL krijg ik "Invalid state, the Connection object is closed":

code:

...
Caused by: org.hibernate.exception.GenericJDBCException: could not inspect JDBC autocommit mode
    at org.hibernate.exception.SQLStateConverter.handledNonSpecificException(SQLStateConverter.java:82)
    at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:70)
    at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:43)
    at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:29)
    at org.hibernate.jdbc.JDBCContext.afterNontransactionalQuery(JDBCContext.java:338)
    at org.hibernate.impl.SessionImpl.afterOperation(SessionImpl.java:398)
    at org.hibernate.impl.SessionImpl.list(SessionImpl.java:852)
    at org.hibernate.impl.QueryImpl.list(QueryImpl.java:74)
    ... 23 more
Caused by: java.sql.SQLException: Invalid state, the Connection object is closed.
    at net.sourceforge.jtds.jdbc.ConnectionJDBC2.checkOpen(ConnectionJDBC2.java:1305)
    at net.sourceforge.jtds.jdbc.ConnectionJDBC2.getAutoCommit(ConnectionJDBC2.java:1715)
    at org.apache.tomcat.dbcp.dbcp.DelegatingConnection.getAutoCommit(DelegatingConnection.java:241)
    at org.apache.tomcat.dbcp.dbcp.PoolingDataSource$PoolGuardConnectionWrapper.getAutoCommit(PoolingDataSource.java:221)
    at org.hibernate.jdbc.ConnectionManager.isAutoCommit(ConnectionManager.java:128)
    at org.hibernate.jdbc.JDBCContext.afterNontransactionalQuery(JDBCContext.java:328)
    ... 26 more

edit: ik bedenk me net dat dit misschien ook aan de code kan liggen die misschien niet de Hibernate Session sluit (niet mijn code ); een andere pagina doet het wel weer na 1x de volgende exception:

code:

Caused by: java.sql.SQLException: Already closed.
    at org.apache.tomcat.dbcp.dbcp.PoolableConnection.close(PoolableConnection.java:77)
    at org.apache.tomcat.dbcp.dbcp.PoolingDataSource$PoolGuardConnectionWrapper.close(PoolingDataSource.java:180)
    at org.hibernate.connection.DatasourceConnectionProvider.closeConnection(DatasourceConnectionProvider.java:64)
    at org.hibernate.jdbc.ConnectionManager.closeConnection(ConnectionManager.java:327)
    ... 25 more

Ik ga nog even verder proberen; misschien ligt het probleem toch in het closen van Hibernate Sessions in onze code...

edit2: Dit bleek inderdaad een probleem in onze code te zijn waardoor de ThreadLocal met de Hibernate Session niet werd gesloten; na dit te hebben gefixt werkt alles goed. (Toch maar weer eens kijken naar een servlet filter om die Session te sluiten...)

[ Voor 31% gewijzigd door matthijsln op 19-10-2005 10:44 ]