jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martijn Hendriks <marti...@gx.nl>
Subject RE: JCR 1456 Database connection pooling
Date Wed, 09 Sep 2009 10:34:18 GMT

> > The only alternative I can see is to implement our own connection
> pool, but imho that's unnecessarily re-inventing the wheel.
> I just wanted to know what exactly is required additionally (direct
> and indirect dependencies). I'm not saying it's a problem.

Ok, I misunderstood, sorry.

> > Well...also the cached PreparedStatements from e.g. the BundlePMs
> have been removed.
> Some connection pools do cache PreparedStatement, but we should
> probably verify that it actually works in our case. To find it out
> what JDBC method are called, you could use the H2 database and add
> ;TRACE_LEVEL_FILE=3 to the database URL.

Thanks for the hint. I'll try it. The commons-DBCP library has functionality for caching PreparedStatements.
I can imagine that the caching is more "dynamic" than with the current approach in the trunk
because commons-DBCP can dynamically adjust the pool sizes of the Connection and PreparedStatement
pools, which probably depends on the usage pattern. Furthermore, a component that requests
a connection prepares a statement and then does the same again might get an other connection
the second time for which the statement has not been pooled yet. It would indeed be interesting
to see how the caching performs in the automated tests. Have you any other test scenario's
in mind?

Best regards,

View raw message