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 16:34:37 GMT
Hi Karan,

> Do we really need to close PMF after each test run? I am not very sure 
> why we would do that.
I think the strategy is to release resources after each test run. If we 
change this strategy, at which time would we release resources instead?


    We could adapt a policy of not closing pmf, but
> only those tests which require an explicit closing of pmf would call 
> closePMF() or something like this which would
> 1. explicitly close the pmf in cache (pmf.close())
> 2. flush the cache.
> I think we should remove pmf.close() after each test run, unless there 
> is requirement in the tck that we close pmf after each test.
> Michael Watzek wrote:
>> Hi Craig,
>>> 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.
>> Isn't there an issue at pmf.close()? After each test method, 
>> pmf.close() is called. We would have to avoid that closed pmf 
>> instances are in the cache. But it would not make sense to remove the 
>> pmf instance from the cache, because then it would be empty.
>> Does this mean, you would not close the pmf?
>> Regards,
>> Michael
>>> 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!

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/

View raw message