directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shawn McKinney (JIRA)" <>
Subject [jira] [Resolved] (FC-38) Potential issues on synchronized protected elements
Date Wed, 09 Mar 2016 22:15:41 GMT


Shawn McKinney resolved FC-38.
       Resolution: Fixed
    Fix Version/s:     (was: 1.0.0-RC41)

ehcache is a blocking cache, should not need further locks or synchs.

> Potential issues on synchronized protected elements
> ---------------------------------------------------
>                 Key: FC-38
>                 URL:
>             Project: FORTRESS
>          Issue Type: Bug
>    Affects Versions: 1.0.0-RC39
>            Reporter: Emmanuel Lecharny
>            Priority: Critical
>             Fix For: 1.0.0-RC42
> There are some classes where we protect a field with a synchronized in order to avoid
concurrent modifications. That's ok, except that one should not access the field while it's
being updated. There are a few cases where it's done, and this should be fixed. 
> The way to do it is to use ReentrantReadWriteLock for that : it allows concurrent reads,
unless a write lock is taken. Writes will block other writes and all the reads until it's
> The OrgUnitP and PolicyP are protecting sets while updating it that aren't protected
when read (this is fixed for OrgUnitP)
> The AdminRoleUtil, HierUtil, PsoUtil, UsoUtil are all manipulating a graph object which
is synchronized on update, but not on read. This is probably more complex to fix than for
the OrgUnitP/PolicyP classes.

This message was sent by Atlassian JIRA

View raw message