openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Patrick Linskey (JIRA)" <j...@apache.org>
Subject [jira] Commented: (OPENJPA-160) Reuse BrokerImpl objects
Date Thu, 22 Feb 2007 18:06:07 GMT

    [ https://issues.apache.org/jira/browse/OPENJPA-160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12475108
] 

Patrick Linskey commented on OPENJPA-160:
-----------------------------------------

> 1. Is there a reason why we can't reuse the BrokerImpl objects?

Architecturally, none that I can think of. But we should take care to ensure that BrokerImpl.free()
really does enough work to close up resources appropriately. Also, I'd love to take a look
at some profiling data to see if we can just optimize creation of brokers instead of adding
the complexity of a pool.

> 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?

The two options that I see are a Configuration option and a non-static field in AbstractBrokerFactory.
I think that I prefer making it an OpenJPAConfiguration option, so that it's more easily configurable.
Configuration would look like so:

<property name="openjpa.BrokerPool" value="Size=50"/>

If BrokerImpl.free() purges the data passed in to the newBroker() call, then we should be
able to just use a set. In this scenario, the newBroker() code would then grab something from
the set, populate the obtained broker with the data passed into the newBroker() call, and
return it. 

If BrokerImpl.free() leaves the broker in a state where the data passed into newBroker() is
relevant, then we should create a key (probably a private inner class) that includes that
data in it, and maintain a map of sets, keyed off of that data. 

All things equal, I'd prefer if we could use a Set (the first case).

> 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.

We should use the pooling logic, but allow the user to control the pool size. If this is a
performance benefit, then we should choose some reasonable initial pool size. I have no idea
what 'reasonable' is.

> 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.


Mime
View raw message