db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From karan malhi <karan.ma...@gmail.com>
Subject Re: connection pool settings for c3p0
Date Mon, 19 Sep 2005 16:20:27 GMT
Do we really need to close PMF after each test run? I am not very sure 
why we would do that.   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!
>>
>>
>
>

-- 
Karan Singh


Mime
View raw message