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
signature.asc
Description: Message signed with OpenPGP
