[
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.
