You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jdo-dev@db.apache.org by karan malhi <ka...@gmail.com> on 2005/09/07 22:45:54 UTC
Connection Pooling
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?
--
Karan Singh
Re: Connection Pooling
Posted by karan malhi <ka...@gmail.com>.
Michael W and Michael B,
I found some tests which were closing pmf and then testing it for some
behaviour after pmf was closed. There might be other tests which might
be closing pmf for some reason. So ,I think i have an idea why we are
going with a PMF for each test case. Thanks for all the help.
Michael Watzek wrote:
> 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 <mw...@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/
>>>>>> -------------------------------------------------------------------
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>
>
--
Karan Singh
Re: Connection Pooling
Posted by karan malhi <ka...@gmail.com>.
"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. "
Shouldnt we then declare it static or store it in a ThreadLocal so that
each instance gets the same copy instead (Assuming the instance is being
created by the same thread) of creating its own copy. Anyways, i will
look into JDO_Test in detail this weekend and ask more relevant questions.
Michael Watzek wrote:
> 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 <mw...@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/
>>>>>> -------------------------------------------------------------------
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>
>
--
Karan Singh
Re: Connection Pooling
Posted by Michael Watzek <mw...@spree.de>.
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 <mw...@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/
-------------------------------------------------------------------
Re: Connection Pooling
Posted by karan malhi <ka...@gmail.com>.
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. 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. Does it somehow affect the runtime behaviour if
we use the same PMF for the tests rather than creating new for each test.
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 <mw...@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/
>>>> -------------------------------------------------------------------
>>>>
>>>
>>>
>>>
>>>
>>
>>
>
>
--
Karan Singh
Re: Connection Pooling
Posted by Michael Watzek <mw...@spree.de>.
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 <mw...@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/
-------------------------------------------------------------------
Re: Connection Pooling
Posted by Michael Bouschen <mb...@spree.de>.
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 <mw...@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 Bouschen Tech@Spree Engineering GmbH
mailto:mbo.tech@spree.de http://www.tech.spree.de/
Tel.:++49/30/235 520-33 Buelowstr. 66
Fax.:++49/30/2175 2012 D-10783 Berlin
Re: Connection Pooling
Posted by Karan Malhi <ka...@gmail.com>.
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 <mw...@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/
> -------------------------------------------------------------------
>
--
Karan Malhi
Re: Connection Pooling
Posted by Michael Watzek <mw...@spree.de>.
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/
-------------------------------------------------------------------