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 07:59:53 GMT
> -----Original Message-----
> From: Jukka Zitting [mailto:jukka.zitting@gmail.com]
> Sent: Tuesday, September 08, 2009 6:12 PM
> To: dev@jackrabbit.apache.org
> Subject: Re: JCR 1456 Database connection pooling
> Hi,
> I merged all the recent changes from trunk to the JCR-1456 branch.
> This makes it easier to compare the branch against the trunk and
> eventually to merge the pooling changes back to trunk.

Great, thanks!

> On Tue, Sep 8, 2009 at 5:32 PM, Thomas Müller<thomas.mueller@day.com>
> wrote:
> >> You do need the commons-dbcp library on your classpath
> >
> > I don't know if this acceptable, probably it is. So you would need
> > commons-dbcp-1.2.2.jar, which is 120 KB. What about commons-pool, or
> > other dependencies of commons-dbcp?
> We've typically added or changed a few dependencies in each minor
> release and doing that in Jackrabbit 2.0 is quite OK.
> The size of commons-dbcp and it's dependencies is pretty small
> compared to things like the new POI libraries we're adding in 2.0 to
> implement full text indexing of  OOXML documents.

The only alternative I can see is to implement our own connection pool, but imho that's unnecessarily
re-inventing the wheel.

> >> it is retrieved every time it is needed from a pooling DataSource.
> >
> > Do you know how much this slows down operations? Probably we should
> > try to measure this.
> Agreed, though intuitively the effect of pooling should be negligible
> (a few extra method calls and hash lookups compared to the work that
> happens in the underlying database).

Well...also the cached PreparedStatements from e.g. the BundlePMs have been removed (the ConnectionRecoveryManager
maintained that cache). That might just have a more significant effect on performance.

Best regards,

View raw message