Mailing-List: contact open-jpa-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: open-jpa-dev@incubator.apache.org
Message-ID: <9944193.1170993907153.JavaMail.jira@brutus>
Date: Thu, 8 Feb 2007 20:05:07 -0800 (PST)
From: "Kevin Sutter (JIRA)" <jira@apache.org>
To: open-jpa-dev@incubator.apache.org
Subject: [jira] Commented: (OPENJPA-138) More performance improvements for
 OpenJPA (lib and kernel)
In-Reply-To: <29896884.1170963186433.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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