[
https://issues.apache.org/jira/browse/OPENJPA-138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12471580
]
Kevin Sutter commented on OPENJPA-138:
--------------------------------------
Thanks for the insights, Patrick. Here are some new observations and
assessments...
> Cache the Class instances for Configurations.newInstance()
On further review, I don't think my original idea is going to work as expected.
I was thinking about caching the Class object based on the input clsName
parameter. But, given your warning about multiple classloaders, this won't
work. I suppose I could cache the Class instance based on the both the clsName
and the derivedClassLoader, but due to the processing in the derivedClassLoader
method, we might not save much.
> Cache the Type's ClassLoader instances in ObjectValue.newInstance()
This one I still comfortable with. I was looking to cache the ClassLoader from
the Class parameter (type) passed in with the "type" instance as the key. This
is should be safe, no? Unless you're saying that the Class instance (type) is
not a suitable key.
> 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()
Here again, if I am using the "from" and "to" Class instances as keys to the
hashmaps, shouldn't this caching be safe? I'm looking to keep a hashmap of
"from" Classes that contains another hashmap of the valid "to" Classes that
have been verified. Here again, unless we can't count on these Class instances
to be used as keys, this optimization should be okay.
> Cache the brokers being created along with appropriate cleanup and reopen
> processing in AbstractBrokerFactory (and BrokerImpl)
Correct, I was looking to pool the Brokers. But, the more I look into this,
I'm not as confident on my proposed solution. Let me think about this one a
bit more...
I'm assuming that you are okay with the other ideas (since you didn't highlight
any concerns). Is that a valid assumption?
Specifically, the following optimizations:
o Cache the TransactionManager in JNDIManagedRuntime
o Cache the Type hashcodes for OpenJPAId.hashcode()
o Clean up the close/IllegalStateException processing in AbstractBrokerFactory
and BrokerImpl (gate with TRACE)
Thanks for your help in working through these performance improvements!
Kevin
> 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.
