[ https://issues.apache.org/jira/browse/OPENJPA-160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12476032
]
John Stecher commented on OPENJPA-160:
--------------------------------------
>From the testing that we have done fooling with different prototyped versions and making
different fields in BrokerImpl static to avoid recreation I am pretty (almost 100%) sure the
cost we are looking at here is just that of creating this class in general being expensive.
I would love to have someone else profile the code with different tools than I have at my
disposal and see if they find a different culprit.
WRT pooling I think a reasonable solution would not be to create a massive pool of objects
but just one per thread-id to optimize for the general case. I am assuming that one Broker
per thread is common. I am with everyone else in that I would love to keep configuration
to a minimum overall. I am not a big fan of exposing pool settings to a user as if we decide
to change it later on you might have to support the setting beyond when you really want too.
:-) Any thoughts on why this would not work or can someone enlighten me on what the general
use case is?
Patrick - I would be worried about the Clone being almost as heavy weight as what we are doing
now but need to implement and test it.
> Reuse BrokerImpl objects
> ------------------------
>
> Key: OPENJPA-160
> URL: https://issues.apache.org/jira/browse/OPENJPA-160
> Project: OpenJPA
> Issue Type: Sub-task
> Reporter: Michael Dick
> Attachments: perf2.jpg, perf3.jpg
>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
|