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:49:38 GMT
Hi Michelle,

For this kind of a scenario, we could have a setPMF(Properties props) 
and closePMF() methods in JDO_Test which will modify the cache 

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!

Karan Singh

View raw message