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 Pooling
Date Thu, 08 Sep 2005 16:10:11 GMT
Hi Karan,

> Hi Michael B and Michael W,
> 
> Thanks for the information. This helps me understand the way tests are 
> run. I dont think 10% overhead is that big.
> Can't we share the pmf ? I mean, my understanding is that all tests 
> subclass JDO_Test. So cant we specify the pmf in JDO_Test and the rest 
> of the test cases can inherit it. 
This is exactly, how tests are implemented :-)

The reason why i ask this is, because
> i want to understand if it is required by the TCK tests to obtain a new 
> PMF for each test  case. 
I think it is a requirement that each test obtains a new pmf instance 
and closes that instance finally.

Does it somehow affect the runtime behaviour if
> we use the same PMF for the tests rather than creating new for each test.
Probably yes, because in this case connection pooling would have a 
positive effect on the runtime.

Regards,
Michael

> 
> Michael Watzek wrote:
> 
>> Hi Karan,
>>
>> Michael is right - one VM per configuration, and not one per test class.
>>
>> We still have one pmf instance per test class. Several tests 
>> implemented by the same test class share the same pmf instance, thus 
>> they reuse connections in the same pool.
>>
>> Below, you find results of alltests.conf running without connection 
>> pooling:
>>
>> derby-app-alltests-junit.txt:
>>     ** Tests run: 396, Time: 237 seconds. Failures: 12, Errors: 22
>> derby-dsid-alltests-junit.txt:
>>     ** Tests run: 396, Time: 256 seconds. Failures: 12, Errors: 22
>>
>> Below, you find results of alltests.conf running with connection pooling:
>>
>> derby-app-alltests-junit.txt:
>>     ** Tests run: 396, Time: 272 seconds. Failures: 12, Errors: 22
>> derby-dsid-alltests-junit.txt:
>>     ** Tests run: 396, Time: 270 seconds. Failures: 12, Errors: 22
>>
>> There is a little overhead running with connection pooling (~10%). 
>> Connection pooling does not speed up TCK because most of the test 
>> classes only implement a single test. However, we decided to use 
>> connection pooling.
>>
>> Regards,
>> Michael
>>
>>> Hi Karan,
>>>
>>> I think what Michael W. recalls describes an old version of tck20. In 
>>> the current version we start a JVM per test configuration. The maven 
>>> goal doRuntck.jdori starts a JVM and passes a list of tck20 test 
>>> classes as argument. The configuration specifies a property 
>>> jdo.tck.classes which includes this list of test classes.
>>>
>>> Michael W. will run the tck w/o connection pooling and send out email 
>>> with the results.
>>>
>>> Regards Michael
>>>
>>>
>>>> Thanks Michael,
>>>>
>>>> Was it a requirement of the TCK to start a seperate VM for each test 
>>>> ? The reason why i ask this is because it takes more time to create 
>>>> a connection pool , and with 396 tests this also contributes to the 
>>>> time the tests take to execute.
>>>> On 9/8/05, Michael Watzek <mwa.tech@spree.de> wrote:
>>>>
>>>>> Hi Karan,
>>>>>
>>>>>
>>>>>> It seems like the tests are trying to create a connection pool 
>>>>>> with each
>>>>>> test. Is there any reason we are not getting the pool just once at

>>>>>> the
>>>>>> start of the test and then reusing connections from that pool?
>>>>>>
>>>>>
>>>>> Each TCK test class is executed using a separate VM. Some test classes
>>>>> implement more than a single test cases. All test cases implemented by
>>>>> the same test class share the same pmf instance. These test cases
>>>>> benefit from connection pooling since the pool is attached to the pmf
>>>>> instance.
>>>>>
>>>>> However, most of the test classes implement only one test case. These
>>>>> test cases can not benefit from connection pooling.
>>>>>
>>>>> Regards,
>>>>> Michael
>>>>> -- 
>>>>> -------------------------------------------------------------------
>>>>> 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/
>>>>> -------------------------------------------------------------------
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
> 


-- 
-------------------------------------------------------------------
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