openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kevin Sutter (JIRA)" <j...@apache.org>
Subject [jira] Commented: (OPENJPA-138) More performance improvements for OpenJPA (lib and kernel)
Date Fri, 09 Feb 2007 04:05:07 GMT

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


Mime
View raw message