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 "Michelle Caisse (JIRA)" <ji...@apache.org> on 2005/09/19 19:28:27 UTC
[jira] Created: (JDO-138) Cache pmf instances
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
[jira] Resolved: (JDO-138) Cache pmf instances
Posted by "Craig Russell (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/JDO-138?page=all ]
Craig Russell resolved JDO-138:
-------------------------------
Fix Version: JDO 2 final
Resolution: Fixed
> Cache pmf instances
> -------------------
>
> Key: JDO-138
> URL: http://issues.apache.org/jira/browse/JDO-138
> Project: JDO
> Type: Improvement
> Components: tck20
> Reporter: Michelle Caisse
> Assignee: Michael Bouschen
> Fix For: JDO 2 final
>
> 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
[jira] Commented: (JDO-138) Cache pmf instances
Posted by "Craig Russell (JIRA)" <ji...@apache.org>.
[ 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
[jira] Assigned: (JDO-138) Cache pmf instances
Posted by "Craig Russell (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/JDO-138?page=all ]
Craig Russell reassigned JDO-138:
---------------------------------
Assign To: Michael Bouschen
> Cache pmf instances
> -------------------
>
> Key: JDO-138
> URL: http://issues.apache.org/jira/browse/JDO-138
> Project: JDO
> Type: Improvement
> Components: tck20
> Reporter: Michelle Caisse
> Assignee: Michael Bouschen
> Fix For: JDO 2 final
>
> 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