[ https://issues.apache.org/jira/browse/FC-38?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14193168#comment-14193168 ]
Emmanuel Lecharny commented on FC-38: ------------------------------------- My first 'fix' (so called) is not correct. One can't acquire a write lock when a read lock is already hold by the thread. I'm trying to find a solution that actually works... > Potential issues on synchronized protected elements > --------------------------------------------------- > > Key: FC-38 > URL: https://issues.apache.org/jira/browse/FC-38 > Project: FORTRESS-CORE > Issue Type: Bug > Affects Versions: 1.0.0-RC39 > Reporter: Emmanuel Lecharny > Priority: Critical > Fix For: 1.0.0-RC40 > > > 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)