[
https://issues.apache.org/jira/browse/OPENJPA-160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12476744
]
Kevin Sutter commented on OPENJPA-160:
--------------------------------------
> IIRC, we're operating in a commit-then-review mode in OpenJPA. This issue has
> been very experimental by nature up earlier today, so I was providing patches
> to find something that worked. Once we got there, I committed, Abe reviewed,
> we changed it. Seems pretty much exactly like how we've handled other issues,
> except that we did a bunch of code-collaboration along the way.
I can see both sides of the argument. If you look at the history on this
Issue, there has been lots of discussion, several alternative proposals,
several patches considered and tested, and an eventual fix that is acceptable
to most everybody. Maybe waiting one day after posting the "final" patch would
have been a good compromise before committing the code. Not that we have to do
this with every JIRA Issue, but ones like this that attract so much attention
and discussion may be good candidates. The extra day would have allowed Abe to
get his comments recognized and Craig would have been able to voice his
"default action" concern. And, anybody that couldn't wait for the commit to
happen could always apply the patch.
> Personally, I prefer more forgiving defaults when possible, so that people
> don't get bitten when they're just playing around with things. Also, if we
> decide to change our defaults, I think that we should include
> openjpa.DataCache, openjpa.QueryCache, and possibly other things listed in
> the optimization guide in such a change.
Here again, I can see both sides (in a wishy-washy mood). Safe defaults are
good to protect the naive users. But, having good performance out of the box
is a benefit -- not only for the customer, but also for all of us so that we
don't have to explain why we're "protecting" the customer from him/herself.
Patrick has a good point. He basically is following suit with the existing
OpenJPA behavior in regards to existing optimizing configuration parameters.
Maybe we should open a JIRA issue to track this concern. We could discuss all
of these optimization parameters and which should be defaulted to which values.
Kevin
> Reuse BrokerImpl objects
> ------------------------
>
> Key: OPENJPA-160
> URL: https://issues.apache.org/jira/browse/OPENJPA-160
> Project: OpenJPA
> Issue Type: Sub-task
> Reporter: Michael Dick
> Assigned To: Patrick Linskey
> Attachments: newprofile.jpg, openjpa-160-clone-patch.txt,
> openjpa-160-finalization-and-cloning-patch.txt, openjpa-160-patch.txt,
> openjpa-160-patch.txt, openjpa-160-patch.txt, openjpa-160-patch.txt,
> perf2.jpg, perf3.jpg, profile_clonepatch.jpg, profile_explicitclass.jpg
>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
