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-138) More performance improvements for OpenJPA (lib and kernel)
Date Fri, 09 Feb 2007 06:44:05 GMT

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

Patrick Linskey commented on OPENJPA-138:
-----------------------------------------

> This is should be safe, no? Unless you're saying that the Class instance (type) is not
a suitable key. 

To be honest, I didn't look at the source for any of the code that you mentioned. My concerns
about classes and classloaders were based solely on seeing "cache" and "class" and "classloader"
all occurring together. I expect that some of the hotspots that you have identified can be
safely cached.

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

Generally-speaking, pooling concerns me. It's tough to get it right without introducing scalability
bottlenecks. I think that we should be sure to demonstrate that  there's a big performance
win involved before implementing something like this.

Also, theoretically, creating a new Broker should be pretty quick. There are a number of bookkeeping
data structures in a Broker, but not *that* many.

> Cache the TransactionManager in JNDIManagedRuntime

Seems safe to me, although I'm neither a JNDI expert nor a JTA expert, so can't comment on
any issues that might come up with security principals or other contextual data if we do cache
things. 

I'm curious, though -- I thought that in Websphere, there was a direct API that you could
invoke to get the TM. To the extent that we can avoid using JNDI altogether for commonly-used
appservers, I imagine that JNDI optimization isn't going to bring that much bang for the buck.

> Cache the Type hashcodes for OpenJPAId.hashcode()

Seems legit. An ID refers to an instance; the type of an instance doesn't change over time.

> Clean up the close/IllegalStateException processing in AbstractBrokerFactory and 
> BrokerImpl (gate with TRACE)

Yeah, this should definitely help things out.

Of course, with all the above issues, numbers don't lie. So, if there are significant performance
improvements to be had, we should look into doing the work to make them available, whether
that means additional code complexity or additional configuration options etc.

> 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