Drew Wills wrote:
I think a user can actually have multiple layouts loaded. In the database I believe layouts are keyed via userId (numeric) and profileId (numeric). You might want to look at using a composite of those two values for the cache key to ensure we don't add unneeded restriction to the object model.Eric, Good questions... Eric Dalquist wrote:This sounds great, just the sort of thing I was hoping for with the better caching backend.A few questions: 1. How are the cache entries keyed?By username, as it stands. I'm not aware of (1) a way that a single user can have more than one layout loaded in memory, nor (2) a way that multiple people can have the same username (in fact this situation would wreak havoc).
Ah yes, I was confused as to what we were talking about. The layout doesn't have any sort of current cache key generation so no issue there. The changing when logged in issue is ok I think, we'll just ship with a default idle expire time of 30 minutes which would match session timeouts. We may also want to look into expanding on the user-attribute cache expiration at logout code that was recently added to ensure the layout is re-loaded after a user logs out/in.2. Does this change the cached entry invalidation logic at all from the existing code?I don't think so, but perhaps I don't understand the question.We're talking about caching the user's layout DOM, not a theme transform or any rendered content.The cache just replaces a private member variable, such that...- any calls to getLayout() check the cache, but get it from the layoutStore if it's not found- any calls to setLayout() place a new copy in the cache- any methods that previously set the layout to null would now call cache.remove(username), which clears the way for getLayout() to pull from the layoutStore on the next call the getLayout()It *does* change the behavior of the portal in one, uncommon scenario: it's possible that your layout can change while you're logged in (without your direct manipulation), based on a fragment layout changing or somesuch.This possibility is considered desirable by some; those who consider it undesirable would be able to configure the LAYOUT_CACHE in a manner that would prevent it.
Oh well, that can be another future enhancement. Along with re-doing that DLM fragment thread as a spring scheduled task.3. Does this also move the DLM fragment cache into a managed cache as well?I wish.The layouts of the actual user accounts that own the fragments would be cached, but DLM uses a different data structure to store the "fragmentized" layout objects it use to build composite layouts.
drew wills
This all sounds good. Lets take another look at the cache key and then get this in for 3.1
-Eric
smime.p7s
Description: S/MIME Cryptographic Signature
