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