Yes, I guess i have enough information.
Karan Singh Senior Technical Consultant Learnquest -----Original Message----- From: Craig Russell [mailto:[EMAIL PROTECTED] Sent: Mon 9/19/2005 1:51 PM To: jdo-dev@db.apache.org Subject: Re: connection pool settings for c3p0 Hi Michael, On Sep 19, 2005, at 10:11 AM, Michael Watzek wrote: > Hi Craig, > > >> Hi, >> The reason to close the pmf is to gracefully close the underlying >> files. This was a requirement of the original FOStore >> implementation, and I don't remember exactly why we wanted to do >> that, but we did. >> > I recall the same. If the files are not closed, then the file > descriptors are not released (unless the OS releases them > implicitly at application shutdown). The FOStore implementation registers a shutdown hook with the VM so it can clean up. I recall this was added after the TCK tests were all done. > > >> It's worth experimenting with this to see if we can avoid closing >> the PMF in case we are running multiple tests. We might need a >> maven postGoal to close the pmf after all the tests have run. >> > That would start another VM, right? Doh! > I think, we need to close before VM shutdown. We can implement a > shutdown hook, or we close PMF in BatchTestRunner. This sounds like the right answer. BTR knows when all the tests in the VM have been run. Karan, is this enough information for you to take a look at improvement? Thanks, Craig > > Regards, > Michael > >> Craig >> On Sep 19, 2005, at 9:48 AM, Michelle Caisse wrote: >> >>> There are some tests in api.persistencemanagerfactory that close >>> or attempt to close the pmf, so that would have to be tested for. >>> >>> A new Properties is passed with each invocation of >>> BatchTestRunner by maven, that is with each separate >>> configuration. However, some tests set pmf properties. In those >>> cases, the pmf would have to be closed and a new one created for >>> the next test. >>> >>> -- Michelle >>> >>> 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: 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! >>>> >>>> >>>> >>>> >>> >>> >>> >> 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! >> > > > -- > ------------------------------------------------------------------- > 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!
