jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matej Knopp" <matej.kn...@gmail.com>
Subject Re: Connection pooling
Date Thu, 17 Jul 2008 17:07:08 GMT

i think the easiest solution would be if jackrabbit instantiated and
maintained DataSource instances. This gives the most flexibility.

If someone wants to get a data source from JNDI it would be only
matter of using the right (proxied) data source.

       <DataSource id="ds1" class="...JndiDataSource">
               <param name="jndiName" value="..."/>

or you can have datasource from the connection pool, e.g.
   <DataSource id="ds2" class="...C3P0DataSource">
        <param name="url" value="jdbc:postgresql:jackrabbittest"/>
        <param name="user" value="postgres"/>
        <param name="password" value="postgres"/>

Just because jackrabbit would manage the data sources it doesn't mean
it should do the pooling, etc. The DataSources it instantiates could
be just simple proxies to JNDI, spring, or whatever else that would
manage the datasources.

This way jackrabbit could leverage container data source management
without having any direct dependencies that would prevent it from
running standalone.


On Thu, Jul 17, 2008 at 6:47 PM, Thomas Müller <thomas.mueller@day.com> wrote:
> Hi,
> I am trying to understand both Matej and Alexander / Marcel...
> In my view Jackrabbit should be able to obtain database connections
> using a JDBC URL as well as a data source name. If Jackrabbit requires
> some kind of connection pooling, that should be integrated in
> Jackrabbit - otherwise it is not possible to use Jackrabbit in a
> standalone application. Otherwise FirstHop couldn't be started from
> the command line.
> It's not required to explicitly declare data sources in
> repository.xml, and I believe it should not be declared because it is
> added complexity for the user of Jackrabbit. Connection pooling can be
> implemented in another way, for example as it is done in the
> DbDataStore now, or using commons-dbcp. Maybe there is even a simpler
> solution, I don't know yet. I guess we should try to find a better
> solution for this problem.
> Regards,
> Thomas

View raw message