Hi Matt,

It depends on the realm implementation.  By default, the out-of-the-box
realms will hit the cache if enabled (because that's usually better than a
round trip to a traditional data store per check).  For more targeted
performance enhancements, a Realm implementation could send all permission
strings to a data store to be checked all at once and get a single
result/answer, or maybe even use a tiered cache approach (local in-memory
first, then network cache, then finally the data store).

There is no multi-tiered cache approach within Shiro today, but it'd be
easy enough to implement: A CacheManager implementation would return Cache
instances that just 'wrap' two caches: a local in-memory one and then falls
back to the networked one.

That said, if you have any improvements or suggestions, we're open to
them!  Do you have an idea of how you'd like this to work for the
out-of-the-box realm implementations?

HTH,

--
Les Hazlewood | @lhazlewood
CTO, Stormpath | http://stormpath.com | @goStormpath | 888.391.5282

On Tue, Dec 9, 2014 at 6:02 AM, brndmg <[email protected]> wrote:

> Should the isPermitted(List<Permission> permissions) be hitting the cache
> for
> every permission in the list?
>
> From the docs it states that "This is primarily a performance-enhancing
> method to help reduce the number of isPermitted(java.lang.String)
> invocations over the wire in client/server systems."
>
> If our cache is on redis, this is definitely not a reduction in
> "over-the-wire" requests.
>
> Is our implementation flawed, or is this expected behavior?
>
> Thanks,
> Matt S.
>
>
>
> --
> View this message in context:
> http://shiro-user.582556.n2.nabble.com/Subject-isPermitted-List-Permission-permissions-hitting-the-cache-for-every-permission-tp7580357.html
> Sent from the Shiro User mailing list archive at Nabble.com.
>

Reply via email to