Hi Craig/Michael,
+1 on this strategy.
I was also thinking about other available options like ThreadLocal,
where we could add the PMF to the ThreadLocal object one time at start
of tests.
Plus we should also set some connection pool size instead of going with
defaults of c3p0/dbcp.
The only thing i would like to ask here is that , is there any testcase
which requires that PMF should be garbage collected on close ?
"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."
Michael, this is an interesting point. Does JPOX support this behaviour?
Is this the default behaviour of an implementation or do we have to
specify a vendor specific property/extension?
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:[EMAIL PROTECTED]
Sent: Mon 9/19/2005 8:26 AM
To: [email protected] <mailto:[email protected]>
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 [EMAIL PROTECTED] Engineering GmbH
mailto:[EMAIL PROTECTED] 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:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!
--
Karan Singh
