So I changed it to this locally...
String key = getKey( contextId );
LOG.info("Getting graph for key " + contextId);
SimpleDirectedGraph<String, Relationship> graph = (
SimpleDirectedGraph<String, Relationship> ) roleCache
.get( key );
if(graph == null){
LOG.info("Graph was null, creating... " + contextId);
return loadGraph( contextId );
}
else{
LOG.info("Graph found in cache, returning...");
return graph;
}
That seems to have fixed the problem. It will be a few days before I can change
the other methods that use the pattern and test it out on our severs. I'm not
following why it's a problem if multiple threads load the graph data structure.
Worst case, doesn't it just get loaded a few more times than necessary until
the cache gets populated? If loading is that expensive, could we change the
cache to a blocking cache, so the get will block until it's populated?
----- Original Message -----
From: "Emmanuel Lécharny" <[email protected]>
To: [email protected]
Sent: Sunday, March 6, 2016 6:59:50 PM
Subject: Re: LDAP Connection Management
Le 06/03/16 23:50, Shawn McKinney a écrit :
>> On Mar 6, 2016, at 3:52 PM, Chris Pike <[email protected]> wrote:
>>
>> I'm guess I'm not following why the original code wasn't working. Ehcache is
>> thread safe.
> True, but that thread safety doesn’t cover the loading of the graph data
> structure into memory. Including a server roundtrip and traversal of result
> set into the digraph.
That's the pb.
And the complex readWriteLock dance was an attempt to make it thread
safe by allowing a thread to have read access when the graph already
exists, but letting another thread updating the graph.
The original version was using a syncrhonized section instead.
