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 

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.

Reply via email to