[
https://issues.apache.org/jira/browse/FC-38?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14195776#comment-14195776
]
Emmanuel Lecharny commented on FC-38:
-------------------------------------
The pb does not rely in ehcache. When calling ehcache for the graph, if it
exists in it, you will get back a valid set, as what you put is what you will
get, and there is no way a concurrent action could tamper it.
The potential issue is the callGraph() method that can be called concurrently,
but AFAICT, the various classes called for this task are stateless, so at
worst, we would get a different set than the expected one.
Assuming we don't require to have the set that contains the exact state of the
server when we have requested it - ie, we might get back something different at
the end of the method that what teh server would have returned, if no
concurrent thread were running the same method -, then the sync is not required
at all.
Here, I might have overlooked the need for such a lock mechanism, and I *think*
we can rely on ehcache to return something that will be valid whatever happens.
Although, I would be interested to have a thread dump of the blocked app, to
see what was wrong in the mechanism I have put in the code...
> 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)
