[
https://issues.apache.org/jira/browse/OPENJPA-138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12471537
]
Patrick Linskey commented on OPENJPA-138:
-----------------------------------------
> Cache the Class instances for Configurations.newInstance()
> Cache the Type's ClassLoader instances in ObjectValue.newInstance()
> Cache the assignable "from" types and associated value "to" types in
> FetchConfigurationImpl.isAssignable
> Cache the assignable "from" types and associated value "to" types in
> BrokerImpl.newObjectId()
These are all a bit concerning.... whenever Class objects get involved, there's
always the possibility of different thread context classloaders or entities
loaded in different classloaders. We should probably be careful here.
> Cache the brokers being created along with appropriate cleanup and reopen
> processing in AbstractBrokerFactory (and BrokerImpl)
It sounds like what this really means is that you're planning to create a pool
of Brokers. Where will this be beneficial? I'm concerned about the cost of and
uncertainty introduced by a pooling strategy, and the corresponding pool
maintenance logic.
> More performance improvements for OpenJPA (lib and kernel)
> ----------------------------------------------------------
>
> Key: OPENJPA-138
> URL: https://issues.apache.org/jira/browse/OPENJPA-138
> Project: OpenJPA
> Issue Type: Sub-task
> Components: kernel, lib
> Reporter: Kevin Sutter
> Assigned To: Kevin Sutter
>
> As we continue pushing OpenJPA though its paces, we're finding a few
> additional tweaks that help with the performance throughput. This Issue will
> be used to track this next set of improvements. I'll document more detail as
> we determine the correct fixes. Several of the changes relate to caching of
> objects in a hashmap instead of re-creating the objects every time we call
> some of these methods.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
