openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kevin Sutter (JIRA)" <j...@apache.org>
Subject [jira] Commented: (OPENJPA-160) Reuse BrokerImpl objects
Date Wed, 28 Feb 2007 22:41:50 GMT

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


Mime
View raw message