jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matej Knopp (JIRA)" <j...@apache.org>
Subject [jira] Commented: (JCR-1456) Database connection pooling
Date Thu, 14 May 2009 21:23:45 GMT

    [ https://issues.apache.org/jira/browse/JCR-1456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12709596#action_12709596
] 

Matej Knopp commented on JCR-1456:
----------------------------------

> We can always change the superclass.

Well, the superclass methods could pass a context object around that the subclass could use
to store connection.

> Not if it's a member of an extra object that's instantiated per each top level method
call.

Yes, but then the superclass needs to pass this object as method argument. Which is probably
okay.

> For now I'm mostly worried about the patch being more complex than it needs to be. We
can add config entries once the basic functionality is in place.

The problem here is that right now every component (persistence manager, fs, journal, ...)
in jackrabbit is responsible for creating the database connection thus the connection properties
are specified as configuration option for the component. But connection pooling essentially
takes this responsibility from component. So how should the database properties be handled?
Where should the connection pool be configured?

My previous patch solved this in way that allowed propagation of connection properties from
components to connection pool and didn't require any changes to configuration files but that
came at cost of readability and complexity.  Current way of configuring database connections
in jackrabbit assumes the connection is created by the component but this is really not compatible
with connection pools.

The cleanest solution would be to add section in configuration to define data sources and
then way to assign a data source to each component that needs database connection.  This obviously
requires changing the configuration scheme though.

If you have an idea how to configure connection pools and configure the components to use
those pools while preserving current configuration scheme I'd love to know about it. The approach
I tried worked but it resulted in code apparently too complicated to be committed.

There is one way I can imagine connection pooling working without change to configuration
syntax. While parsing the configuration jackrabbit would create datasource (with default connection
pool i.e. dbcp) for each distinct connection properties and then pass this datasource to the
component to which the connection properties belong.

This would make the configuration parsing code bit more complicated but wouldn't require any
change to configuration files.

> So we don't need to implement one. Note that the solution should work with existing Jackrabbit
configurations that do not specify a connection pool. There's no need for DBCP when a JNDI
DataSource is configured, but it makes things a lot easier for non-JNDI configurations.

I agree that jackrabbit should have connection pooling configured by default but that should
be overridable in configuration file. 

> What's SimplePoolingConnectionProvider for then?

That's just a simple connection pool i used for development. It was meant to be kind of "Default"
connection provider and the connection pooling logic should be replaced with DBCP should people
have agried with the approach i taked with the patch.



> Database connection pooling
> ---------------------------
>
>                 Key: JCR-1456
>                 URL: https://issues.apache.org/jira/browse/JCR-1456
>             Project: Jackrabbit Content Repository
>          Issue Type: Improvement
>          Components: jackrabbit-core
>            Reporter: Jukka Zitting
>         Attachments: patch-1456-1.txt, patch-1456-2.txt, patch-1456-3.txt
>
>
> Jackrabbit should use database connection pools instead of a single connection per persistence
manager, cluster journal, or database data store.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message