db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig Russell (JIRA)" <j...@apache.org>
Subject [jira] Commented: (JDO-138) Cache pmf instances
Date Tue, 20 Sep 2005 17:47:28 GMT
    [ http://issues.apache.org/jira/browse/JDO-138?page=comments#action_12330032 ] 

Craig Russell commented on JDO-138:
-----------------------------------

The most common case is that the test simply asks JDO_Test.getPMF() for the PMF associated
by properties with the test run, and most of the tests will use the same properties file and
therefore the same configuration. If getPMF first checks whether there is already a PMF that
was obtained by the same (equals) Properties it can simply use it.

Any test that has its own PMF typically doesn't use the PMF by Properties, so it won't be
affected by the change.

The only place we close the PMF is in tearDown. If we don't close the PMF there, we still
need to close it before exiting the VM. The BatchTestRunner might be the place to finally
close the PMF associated with the tests that were run in the VM. 

The down side of this proposal is that it will expose issues in the connection pool and the
handling of PMs across tests. So it would be prudent to add a system property to disable this
feature, especially useful during initial testing of an implementation. The property would
control reuse of the PMF: jdo.tck.reusePMF with a default of true perhaps?

> Cache pmf instances
> -------------------
>
>          Key: JDO-138
>          URL: http://issues.apache.org/jira/browse/JDO-138
>      Project: JDO
>         Type: Improvement
>   Components: tck20
>     Reporter: Michelle Caisse

>
> In order to improve performance with connection pooling, cache pmf instances in JDO_Test,
rather than closing pmf after each test.
> Some design issues & suggestions:
> [Craig:]
> 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.
> ...
> 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.
> 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.
> [Karan:]
> 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.
> For [tests that need to set pmf properties], we could have a setPMF(Properties props)
and closePMF() methods in JDO_Test which will modify the cache appropriately.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


Mime
View raw message