> On Mar 8, 2016, at 2:08 PM, Chris Pike <[email protected]> wrote:
>
> I tried implementing the suggested code, and while it works in eclipse, when
> running the service, the first run passes, but all subsequent requests hang
> while getting object from the cache.
>
> After looking more closely at the caching code, it is already using a
> blocking cache, which by default will return null on the first get and lock
> indefinitely on subsequent gets until the cache is populated. Perhaps it's
> the combination of our locks and ehcache's locks are causing issues??? I do
> think the blocking cache makes our lock code unnecessary as the cache is
> already handling multiple threads. Thoughts?
>
> I would like to add ability to configure the maxtimeout on the blocking cache
> so indefinite blocks can't happen. If the timeout triggers on multiple gets
> to the blocking cache, it is possible that load graph could be called
> simultaneously. Perhaps this method needs to be synchronized for this
> hopefully unlikely scenario.
Let’s dissect the function in question:
private static SimpleDirectedGraph<String, Relationship> getGraph( String
contextId )
{
1 ReadWriteLock hierLock = HierUtil.getLock( contextId, HierUtil.Type.ROLE
);
2 String key = getKey( contextId );
try
{
3 hierLock.readLock().lock();
4 SimpleDirectedGraph<String, Relationship> graph = (
SimpleDirectedGraph<String, Relationship> ) roleCache
.get( key );
if ( graph == null )
{
try
{
5 hierLock.readLock().unlock();
6 hierLock.writeLock().lock();
7 graph = loadGraph( contextId );
8 hierLock.readLock().lock();
}
finally
{
9 hierLock.writeLock().unlock();
}
}
return graph;
}
finally
{
10 hierLock.readLock().unlock();
}
}
I placed numbers in front of statements that are significant to this
conversation. (Hopefully that formatting is preserved.)
You are proposing removing statements 1,3,5,6,8,9 and 10 - right?
So the question becomes what is left in place to guard statement #7? Entry to
it must be synchronized to one thread at a time. Are you suggesting that
ehcache already maintains synchronicity via either #2, #4, or both?
Shawn