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 13:37:55 GMT
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