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 14:11:43 GMT
This assumes that you are running jackrabbit in environment that
manages DataSources. I think that's a bit far fetched assumptions. So
far I didn't notice jackrabbit having any dependencies on the
environment you are running it within.

And I'm also not really sure about the servlet engine being
responsible for DataSource management. I think the roles are
orthogonal. Some servlet containers manage data sources, some don't
(jetty). I don't think it is a good idea to rely on the servlet
container to manage the data source.

Doing it this way it would be no longer possible to configure the
database connection from repository.xml. Also it could get complicated
for persistence managers that use different database settings for each
workspace (derby).

-Matej

On Thu, Jul 17, 2008 at 12:46 PM, Alexander Klimetschek
<aklimets@day.com> wrote:
> I think we do need a pooling for all the jdbc connections in
> Jackrabbit. But that should be possible without managing DataSources
> within Jackrabbit. DataSource management itself is clearly a task of
> the container or servlet engine and would create too much additional
> code that needs to be maintained - and ensured to be standards
> compliant.
>
> Regards,
> Alex
>
> On Wed, Jul 16, 2008 at 7:30 PM, Matej Knopp <matej.knopp@gmail.com> wrote:
>> Hi,
>>
>> the thing is, not everyone is running jackrabbit in a servlet
>> container and not every servlet container uses JNDI. Also I think
>> creating DataSource that acts as a proxy for another JNDI obtained
>> DataSource should be fairly trivial.
>>
>> -Matej
>>
>> On Wed, Jul 16, 2008 at 2:06 PM, Marcel Reutegger
>> <marcel.reutegger@gmx.net> wrote:
>>> Hi,
>>>
>>> I think jackrabbit should not manage data sources but rather obtain them
>>> through JNDI. there are lots of existing JNDI implementations and containers
>>> that allow you to configure data sources and make them available through
>>> JNDI.
>>>
>>> regards
>>>  marcel
>>>
>>> Matej Knopp wrote:
>>>>
>>>> Hi,
>>>>
>>>> we've encountered a serious problem with jackrabbit - keeping a
>>>> database connection for each active workspace.
>>>> A jira entry already exists [1] and it's targetted for 1.5, but so far
>>>> there hasn't seem to be much activity.
>>>>
>>>> I'm willing to provide a patch that might be of some help to you, but
>>>> first I'd like to have some things clarified of how the thing should
>>>> work (from user perspective).
>>>>
>>>> My idea so far is to have new config section (toplevel, inside
>>>> <Repository>) that would allow to register data sources
>>>>
>>>> Something like
>>>>
>>>>        <DataSource id="ds1" class="com.mypackage.MyDataSource">
>>>>                <param name="url" value="jdbc:postgresql:jackrabbittest"/>
>>>>                <param name="user" value="postgres"/>
>>>>                <param name="password" value="postgres"/>
>>>>        </DataSource>
>>>>
>>>> Multiple data sources could be defined per repository.
>>>>
>>>> Jackrabbit would create and manage data source instances (each class
>>>> is required to implement DataSource interface).
>>>>
>>>> All components that require a SQL connection would have dataSource
>>>> attribute that would specify the data source instance.
>>>>
>>>> i.e.
>>>>
>>>>        <PersistenceManager
>>>>
>>>> class="org.apache.jackrabbit.core.persistence.bundle.PostgreSQLPersistenceManager">
>>>>                <param name="dataSource" value="ds1"/>
>>>>                <param name="schemaObjectPrefix" value="${wsp.name}_"/>
>>>>                <param name="externalBLOBs" value="false"/>
>>>>        </PersistenceManager>
>>>>
>>>> Alternatively there might be also a way to register data source per
>>>> workspace, so the instance would be workspace specific. Though I
>>>> personally don't see much value in this.
>>>>
>>>> It would be great to get any feedback on this.
>>>>
>>>> Kind regards,
>>>> -Matej Knopp
>>>>
>>>> [1] https://issues.apache.org/jira/browse/JCR-1456
>>>>
>>>
>>>
>>
>
>
>
> --
> Alexander Klimetschek
> alexander.klimetschek@day.com
>

Mime
View raw message