openjpa-dev mailing list archives

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

     [ https://issues.apache.org/jira/browse/OPENJPA-826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Fernando updated OPENJPA-826:
-----------------------------

    Attachment: locks-asserts-2.diff

this is a second patch, which only moves the asserts out of the lock.. and puts back some
of the more convoluted null checks..

this one should be more palatable, and should be included.

> 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-2.diff, 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