directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shawn McKinney (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (FC-38) Potential issues on synchronized protected elements
Date Tue, 04 Nov 2014 03:14:33 GMT

    [ https://issues.apache.org/jira/browse/FC-38?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14195636#comment-14195636
] 

Shawn McKinney commented on FC-38:
----------------------------------

I think we are OK leaving the code as is.  The cache mechanism is ehchache blockingcache.
 If the first thread that hits the cache returns a null on the key, ehcache will block subsequent
threads on the get method.  This means we don't have to reimplement the same logic inside
of the cache wrapper:

http://ehcache.org/apidocs/2.7.6/net/sf/ehcache/constructs/blocking/BlockingCache.html

http://www.liferay.com/web/shuyang.zhou/blog/-/blogs/blocking-cache

I can reproduce deadlock inside of fortressdemo2 web app during user signon inside isUserInRole
realm call.  Cannot reproduce using junit tests.

> 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)

Mime
View raw message