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 Sat, 13 Dec 2008 01:12: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.diff

patch to move around some code outside of locks, to make multithreaded support more efficient.

> 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