> On Mar 9, 2016, at 10:00 AM, Chris Pike <[email protected]> wrote: > > Yes, this is what we are currently testing on our servers. > > https://github.com/PennState/directory-fortress-core-1/blob/release/src/main/java/org/apache/directory/fortress/core/impl/RoleUtil.java >
Much simpler. > > On Mar 9, 2016, at 10:00 AM, Chris Pike <[email protected]> wrote: > > I still don't understand why #7 needs guarded, but it is guarded by #4. Since > the cache is a blocking cache, it returns null on first hit, then blocks > until a value is put in the cache. By default, the blocking cache will block > forever, so I set the timeout to 60 seconds as a failsafe. It is possible > (however unlikely) that multiple gets could timeout after 60 seconds and > result in simultaneous loadGraph calls, so I also made the loadGraph method > synchronized. > That’s what I asked you before - is 7 being guarded by 2 or 4: > > On Mar 9, 2016, at 10:00 AM, Chris Pike <[email protected]> wrote: > > 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? Sounds like your answer is ‘yes’ to my question. Statement 7 (call to loadGraph) is guarded by 4. Shawn
