[prev in list] [next in list] [prev in thread] [next in thread] 

List:       xml-cocoon-users
Subject:    Re: Database Connection Leak - When too many pipelines
From:       Paul Joseph <pjoseph () gmail ! com>
Date:       2010-02-12 21:56:12
Message-ID: 4B75CE7C.3030408 () gmail ! com
[Download RAW message or body]

I have to confess my ignorance of Spring's framework...I suggest 
googling on dbcp and data leaks and you may see if the method is common 
to both?

Shahriar Aghajani wrote:
> Thanks Paul.
>
> I'm not certain, but it doesn't look like i'm using commons-dbcp.
>
> I think the spring DriverManagerDataSource is replacing it in this case?
>
> Below is what I'm using for my connector:
>
> Cheers.
>
>   <bean 
> name="org.apache.avalon.excalibur.datasource.DataSourceComponent/workshop_admin" 
> class="org.apache.cocoon.databases.bridge.spring.avalon.SpringToAvalonDataSourceWrapper"> 
>
>
>        <property name="wrappedBean">
>            <bean 
> class="org.springframework.jdbc.datasource.DriverManagerDataSource" >
>              <property name="driverClassName" 
> value="org.postgresql.Driver"/>
>              <property name="url" value="jdbc:postgresql:mydatabase"/>
>              <property name="username" value="myusername"/>
>              <property name="password" value="mypassword"/>
>            </bean>
>        </property>
>
>    </bean>
>
>
>
> Paul Joseph wrote:
>> I vaguely recall having this problem in Cocoon 2.1.11 and that it 
>> seemed to go away when I replaced my commons-dbcp jar with the latest 
>> I could find (commons-dbcp-1.2.2.jar)
>>
>> Shahriar Aghajani wrote:
>>> Hello,
>>>
>>> I wonder if anybody can help me or point me in the right direction.
>>>
>>> I get database connection leaks if I'm including pipelines which 
>>> reference other pipelines too many times.
>>>
>>> I'm using Cocoon 2.2
>>> PostgreSQL 8.3 with postgresql-8.3-605.jdbc3.jar
>>>
>>> Here's what I got:
>>>
>>> Data comes from the parent sitemap, and the child sitemap uses that 
>>> data.
>>> I've tried including the data using map:aggregate, XInclude, 
>>> Include, and XSLT/document()... all lead to the leaks one way or 
>>> another.
>>> For each of the "bad" piplines, I get a new idle postgres connection 
>>> hanging around indefinitely.
>>>
>>> Below,
>>> for the via-agg.xml pipeline, the 3rd include does the job.  If I 
>>> remove that one, then I don't get a leak.
>>> for the via-include.xml pipeline, if I use only one of the "CULPRIT" 
>>> includes, everything is fine.  But if I use any 2 of the includes, 
>>> then I get a leak.
>>>
>>> Any ideas?
>>>
>>>
>>> Thank you very much for your help.
>>>
>>> Regards,
>>> Shahriar Aghajani.
>>>
>>>
>>> Parent Sitemap:
>>>
>>> <map:match pattern="data/first-level.xml">
>>>   <map:generate type="jx" src="wires/sql/first-level.select.jx"/>
>>>   <map:transform type="sql">
>>>      <map:parameter name="use-connection" value="workshop_admin"/>
>>>   </map:transform>
>>>   <map:serialize type="xml"/>
>>> </map:match>
>>>
>>> <map:match pattern="data/second-level.xml">
>>>   <map:generate type="jx" src="wires/sql/first-level.select.jx"/>
>>>   <map:transform type="sql">
>>>      <map:parameter name="use-connection" value="workshop_admin"/>
>>>   </map:transform>
>>>   <map:transform src="wires/sql/first-level.xml.xsl"/>
>>>   <map:serialize type="xml"/>
>>> </map:match>
>>>       <map:match pattern="data/secondB-level.xml">
>>>   <map:generate  src="cocoon:/data/first-level.xml"/>
>>>   <map:transform src="wires/sql/first-level.xml.xsl"/>
>>>   <map:serialize type="xml"/>
>>> </map:match>
>>>
>>> <map:match pattern="sub/**">
>>>   <map:mount check-reload="yes" src="sub/" uri-prefix="sub"/>
>>> </map:match>
>>>
>>>
>>> Sub Sitemap:
>>>
>>> <map:match pattern="local-data/first-level.xml">
>>>   <map:generate src="cocoon://data/first-level.xml"/>
>>>   <map:serialize type="xml"/>
>>> </map:match>
>>> <map:match pattern="local-data/second-level.xml">
>>>   <map:generate src="cocoon://data/first-level.xml"/>
>>>   <map:transform src="../wires/sql/first-level.xml.xsl"/>
>>>   <map:serialize type="xml"/>
>>> </map:match>
>>>
>>>
>>>
>>> <map:match pattern="via-agg.xml">
>>>   <map:aggregate element="page">
>>>      <map:part src="cocoon://data/first-level.xml"/>
>>>      <map:part src="cocoon://data/second-level.xml"/>
>>>      <map:part src="cocoon://data/secondB-level.xml"/>   <!-- TOOOO 
>>> MUCH -->
>>>   </map:aggregate>
>>>   <map:serialize type="xml"/>
>>> </map:match>
>>>
>>>
>>> <map:match pattern="via-include.xml">
>>>   <map:generate src="seed-file.xml"/>
>>>   <map:transform type="include"/>
>>>   <map:serialize type="xml"/>
>>> </map:match>
>>>
>>>
>>> Seed File:
>>>
>>> <page xmlns:i="http://apache.org/cocoon/include/1.0">
>>>
>>>   <data>
>>>      <i:include src="cocoon://data/first-level.xml"/>
>>>      <i:include src="cocoon://data/second-level.xml"/>
>>>      <i:include src="cocoon://data/secondB-level.xml"/>   <!-- 
>>> CULPRIT -->
>>>      <i:include src="cocoon:/local-data/first-level.xml"/>    <!--- 
>>> CULPRIT -->
>>>      <i:include src="cocoon:/local-data/second-level.xml"/>  <!-- 
>>> CULPRIT -->
>>>   </data>
>>>
>>> </page>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
>>> For additional commands, e-mail: users-help@cocoon.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
>> For additional commands, e-mail: users-help@cocoon.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org

[prev in list] [next in list] [prev in thread] [next in thread]