directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shawn McKinney <>
Subject Caching in Fortress Core
Date Fri, 16 Nov 2018 12:18:19 GMT
Many years ago I made a very bad decision that has haunted me ever since — caching.

That’s right, short-term gratification (performance) at the expense of long-term satisfaction.

The biggest drawback, now things like Fortress REST aren’t running entirely stateless, which
prevents running in a load-balanced topology.

So now the thought is how do we drop the cache, or at least find a way to make it responsive
to changes that occur in other nodes.

Before we make the decision to change, it’s probably best to identify all of the entities/relationships
that will be affected.

1. OrgUnit entity validation
2. PwPolicy entity validation
3. AdminRole Hierarchies
4. Perm OU Hierarchies
5. Role Hierarchies
6. User OU Hierarchies
7. Dynamic Separation of Duty Constraints
8. Static Separation of Duty Constraints

1&2 are trivial, simply contain lists of entity names, that are validated when added as
a relationships to other entity — users mostly) but also Perms.

The hierarchies are more about functionality. That is the entities that comprise a particular
hierarchy, e.g. Roles, are stored flat, under a single ou, but their structure is contained
within a Graph datastructure, that is stored in cache, and interpreted during runtime - i.e.
is this role a parent of another roles.

Same is true for the OU hiers.

The SoD caches are the entire list of elements that comprise dynamic and static constraints,
used during the validation, e.g. is can this role be assigned or activated.

I believe there are a couple of directions we can take.

a. Continue to use the cache, but now have a listener attached to the data persistence that
notifies of change, and triggers a refresh.

b. Remove the cache entirely and just pay for the cost.

I’d say ‘a’ if the complexity and overhead isn’t great other b.

— Shawn

View raw message