db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Watzek <mwa.t...@spree.de>
Subject Re: connection pool settings for c3p0
Date Mon, 19 Sep 2005 17:11:49 GMT
Hi Craig,

> Hi,
> 
> The reason to close the pmf is to gracefully close the underlying files. 
> This was a requirement of the original FOStore implementation, and I 
> don't remember exactly why we wanted to do that, but we did.
I recall the same. If the files are not closed, then the file 
descriptors are not released (unless the OS releases them implicitly at 
application shutdown).

> 
> It's worth experimenting with this to see if we can avoid closing the 
> PMF in case we are running multiple tests. 
> 
> We might need a maven postGoal to close the pmf after all the tests have 
> run.
That would start another VM, right? I think, we need to close before VM 
shutdown. We can implement a shutdown hook, or we close PMF in 
BatchTestRunner.

Regards,
Michael
> 
> Craig
> 
> On Sep 19, 2005, at 9:48 AM, Michelle Caisse wrote:
> 
>> There are some tests in api.persistencemanagerfactory that close or 
>> attempt to close the pmf, so that would have to be tested for.
>>
>> A new Properties is passed with each invocation of BatchTestRunner by 
>> maven, that is with each separate configuration.  However, some tests 
>> set pmf properties.  In those cases, the pmf would have to be closed 
>> and a new one created for the next test.
>>
>> -- Michelle
>>
>> Craig Russell wrote:
>>
>>
>>> Hi,
>>>
>>> It might be worthwhile looking at the JDO_Test method where the PMF 
>>> is acquired. Perhaps a static Map that holds the PMF between tests 
>>> would work. The thing to watch for is to make sure that the PMF 
>>> that's cached fully meets the requirements of the Properties/Map that 
>>> is being used. There is some logic there.
>>>
>>> I think that for most cases in the tck, the identical Properties is 
>>> being passed in and maybe all we need is to have JDO_Test make a copy 
>>> of the PMF properties and a reference to the PMF and if the 
>>> properties matches the cached Properties, return the cached PMF.
>>>
>>> We need to make sure that this doesn't interfere with the PMF that 
>>> uses a different Properties by design.
>>>
>>> Craig
>>>
>>> On Sep 19, 2005, at 6:14 AM, Michael Watzek wrote:
>>>
>>>
>>>> Hi Karan,
>>>>
>>>>
>>>>
>>>>> Hi Michael,
>>>>> I have noticed one thing in the tests. The BatchTestRunner creates 
>>>>> a new object for each TestCase and then calls the test() method. 
>>>>> Since each one of them inherits the pmf instance variable, dont you 
>>>>> think that with each test we are trying to get a new pmf and that 
>>>>> initiates creation of a new pool of connections. This might be the 
>>>>> reason connection pooling is slower than running tests without 
>>>>> connection pooling. That 10% of overhead when we run tests with 
>>>>> connection pooling, is in my opinion the time taken to create that 
>>>>> pool (thats what it looks like when i looked at the JPOX RDBMS log 
>>>>> earlier).
>>>>>
>>>>>
>>>> Right! Each test method calls the JDO implementation returning a pmf 
>>>> instance. Finally, the test method calls pmf.close() and nullifies 
>>>> the variable holding the pmf instance.
>>>>
>>>> Provided, that each getPMF() call creates a new pmf instance, then 
>>>> we do not benefit from connetion pooling because the pool is bound 
>>>> to a pmf instance (as you mentioned above). That's what we see when 
>>>> we run TCK20 with JPOX.
>>>>
>>>> However, a JDO implementation may return the same pmf instance if 
>>>> you pass the same properties to getPMF in subsequent calls. Such 
>>>> implementations would benefit from connection pooling when they are 
>>>> called by TCK20.
>>>>
>>>> Regards,
>>>> Michael
>>>>
>>>>
>>>>
>>>>
>>>>> I might be wrong, because i havent had the time to understand the 
>>>>> JDO_Test class fully. If I am wrong, then I think it might be worth 
>>>>> a try to increase the connection pool size a little bit, just to 
>>>>> see if it speeds up the tests.
>>>>> I will try it and let you know. Thanks for the info on c3p0 properties.
>>>>>  Karan Singh
>>>>> Senior Technical Consultant
>>>>> Learnquest
>>>>> -----Original Message-----
>>>>> From: Michael Watzek [mailto:mwa.tech@spree.de]
>>>>> Sent: Mon 9/19/2005 8:26 AM
>>>>> To: jdo-dev@db.apache.org <mailto:jdo-dev@db.apache.org>
>>>>> Subject: Re: connection pool settings for c3p0
>>>>>  Hi Karan,
>>>>> up to now there is no file "c3p0.properties". Thus, we run C3P0 
>>>>> using the default configuration. Do you think we can benefit from 
>>>>> changing the default? The right place for such a file would be 
>>>>> under test/conf.
>>>>> Regards,
>>>>> Michael
>>>>>
>>>>>
>>>>>> Where are we doing connection pool settings for c3p0? I couldnt 
>>>>>> find the c3p0.properties file anywhere
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>>> -- 
>>>> -------------------------------------------------------------------
>>>> Michael Watzek                  Tech@Spree Engineering GmbH
>>>> mailto:mwa.tech@spree.de        Buelowstr. 66
>>>> Tel.:  ++49/30/235 520 36       10783 Berlin - Germany
>>>> Fax.:  ++49/30/217 520 12       http://www.spree.de/
>>>> -------------------------------------------------------------------
>>>>
>>>>
>>>
>>> Craig Russell
>>>
>>> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
>>>
>>> 408 276-5638 mailto:Craig.Russell@sun.com
>>>
>>> P.S. A good JDO? O, Gasp!
>>>
>>>
>>>
>>
>>
> 
> Craig Russell
> 
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
> 
> 408 276-5638 mailto:Craig.Russell@sun.com
> 
> P.S. A good JDO? O, Gasp!
> 
> 


-- 
-------------------------------------------------------------------
Michael Watzek                  Tech@Spree Engineering GmbH
mailto:mwa.tech@spree.de        Buelowstr. 66
Tel.:  ++49/30/235 520 36       10783 Berlin - Germany
Fax.:  ++49/30/217 520 12       http://www.spree.de/
-------------------------------------------------------------------

Mime
View raw message