Hi Michael,
In that case we should not use connection pooling at all. The reason is
that even if the JDO implementation returns back the same connection
pool if given the same pmf properties file again, then it appears that
the implementation does not get rid of the connection pool and gives it
back to you when you get another pmf with same properties, which would
break our strategy of releasing resources after each test. We will have
to define what resources need to be released.
What do you think?
Michael Watzek wrote:
Hi Karan,
Do we really need to close PMF after each test run? I am not very
sure why we would do that.
I think the strategy is to release resources after each test run. If
we change this strategy, at which time would we release resources
instead?
Regards,
Michael
We could adapt a policy of not closing pmf, but
only those tests which require an explicit closing of pmf would call
closePMF() or something like this which would
1. explicitly close the pmf in cache (pmf.close())
2. flush the cache.
I think we should remove pmf.close() after each test run, unless
there is requirement in the tck that we close pmf after each test.
Michael Watzek wrote:
Hi Craig,
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.
Isn't there an issue at pmf.close()? After each test method,
pmf.close() is called. We would have to avoid that closed pmf
instances are in the cache. But it would not make sense to remove
the pmf instance from the cache, because then it would be empty.
Does this mean, you would not close the pmf?
Regards,
Michael
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: 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 [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
