You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by "Shawn McKinney (JIRA)" <ji...@apache.org> on 2016/03/09 23:15:41 UTC
[jira] [Resolved] (FC-38) Potential issues on synchronized
protected elements
[ https://issues.apache.org/jira/browse/FC-38?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Shawn McKinney resolved FC-38.
------------------------------
Resolution: Fixed
Fix Version/s: (was: 1.0.0-RC41)
1.0.0-RC42
ehcache is a blocking cache, should not need further locks or synchs.
> Potential issues on synchronized protected elements
> ---------------------------------------------------
>
> Key: FC-38
> URL: https://issues.apache.org/jira/browse/FC-38
> 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 done.
> 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
(v6.3.4#6332)