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