jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stefan Guggisberg" <stefan.guggisb...@day.com>
Subject Re: Connection pooling
Date Fri, 18 Jul 2008 11:09:23 GMT
On Thu, Jul 17, 2008 at 9:09 PM, Matej Knopp <matej.knopp@gmail.com> wrote:
> 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.
> What should such integration look like? Would you allow the user to
> chose the connection pooling implementation or would you "hardcode"
> one? What if user already has connection pooling infrastructure in
> place (but not one exported by JNDI)?
> I still don't quite understand what is the big issue with managing
> DataSource instances. We are not talking about writing an IoC
> container here. All that would do is a simple map <id> ->
> <dataSourceInstance> where dataSourceInstance is a simple java bean
> implementing DataSource.
> If user wants jndi, the bean would be simple JNDI DataSource proxy.
> C3P0 or commons-dbcp have their own data source classes already that
> could be easily configured. Or user could provide a DataSource that
> would proxy calls to a spring/guice/hivemind managed beans.
> All of those would be trivial to write and configure.
> One of the annoyances with jackrabbit apart from the fact that it
> keeps db connections opened is that it only provides two options to
> obtain the actual connections. Either through JNDI or it creates the
> connections on it's own. But there is a good reason why the DataSource
> interface was introduced. I really don't think it is a good idea to
> have Jackrabbit creating database connections without having a simple
> way to override this behavior.

DataSource et al are fine for client/user applications. jackrabbit OTOH is an
infrastructure app and therefore needs exclusive control over the persistence
layer (i.e. jdbc connections in this case). with hindsight i regret i
did implement
the jdbc persistence manager in the first place (it was meant as a
proof of concept
only). but that's a different story and just my very personal view ;)


> -Matej

View raw message