[
https://issues.apache.org/jira/browse/OPENJPA-160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12475102
]
Michael Dick commented on OPENJPA-160:
--------------------------------------
Another performance issue we've run into is the overhead of creating a new
BrokerImpl object when the application calls createEntityManager. The JPA spec
clearly states that the provider needs to return a new EntityManager instance,
and we're not trying to circumvent that requirement. However it seems plausible
that we could reuse the underlying BrokerImpl object, once all the persistence
data has been cleared (ie after BrokerImpl.free has been called). Implementing
a fairly simple object reuse pool resulted in a significant performance
improvement in our testing. I don't see this as being a violation of the intent
of the spec, but I'd rather get a sense of consensus before I/we go any
further.
Questions :
1. Is there a reason why we can't reuse the BrokerImpl objects?
2. Assuming we can reuse the objects, where should we put the reuse pool? The
original implementation created a static map in AbstractBrokerFactory. I'm not
sure that's the best place for it though. BrokerImpl isn't a final class it's
possible that different configurations could use different broker
implementations (through the broker plugin). Maybe we need a new plugin which
indicates that class to use as a Broker pool?
3. Should we pool the broker instances by default? I think we'll want this to
be configurable, but I'm not sure it needs to be on by default.
Justification :
We've been running tests with the Sun Application Server and adding in a
BrokerImpl reuse pool brings the performance on par with Hibernate.
> Reuse BrokerImpl objects
> ------------------------
>
> Key: OPENJPA-160
> URL: https://issues.apache.org/jira/browse/OPENJPA-160
> Project: OpenJPA
> Issue Type: Sub-task
> Reporter: Michael Dick
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
