openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Fernando (JIRA)" <j...@apache.org>
Subject [jira] Commented: (OPENJPA-826) moving some code outside of lock boundaries, that don't need to be locked
Date Mon, 15 Dec 2008 18:53:44 GMT

    [ https://issues.apache.org/jira/browse/OPENJPA-826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12656693#action_12656693
] 

Fernando commented on OPENJPA-826:
----------------------------------

OK.  So maybe I was being a little overzealous. but I'm pretty sure, all of the assertOpen/NotReadOnly/NotSerialized
methods can go outside the lock.

for the few places where I also moved out the null checks, I guess we should double them up
to be extra sure..

Would you like me to submit a different patch that only moves out the asserts?

Another patch I would definitely add is to add the locks inside of the compilation methods,
instead of putting locks every the compilation methods are called.. then within the compilation
method I would add a short-circuit, that would simply exit if its already been compiled..
 Then a lot of the boilerplate code would go away..

> moving some code outside of lock boundaries, that don't need to be locked
> -------------------------------------------------------------------------
>
>                 Key: OPENJPA-826
>                 URL: https://issues.apache.org/jira/browse/OPENJPA-826
>             Project: OpenJPA
>          Issue Type: Improvement
>          Components: kernel
>    Affects Versions: 2.0.0
>            Reporter: Fernando
>         Attachments: locks-asserts.diff
>
>
> I am reviewing code because of slices concurrency/multithreaded issues, and I see that
some code in QueryImpl was too aggressive in their locks.  So I reviewed QueryImpl and BrokerImpl...
> Mainly: assertMethods do not need to be within the lock.
> Then I found a few methods that were doing precondition/shortcut checking, but all within
locks, so that seemed like a waste:
> 1) QueryImpl.setCandiateExtent; checks to see if value setting is same as current value
> 2) these places check to see if it needs to calculate the value of not:
> QueryImpl.isUnique, QueryImpl.setCandiateExtent, QueryImpl.getCandidateType, QueryImpl.getResultType,
QueryImpl.getParameterDeclaration

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