Skip to content
This repository has been archived by the owner on Mar 11, 2020. It is now read-only.

Consolidate Caching (Dynamite-2013) and Cache (Dynamite-2010) namespaces (code dupe) #6

Open
taoneill opened this issue Apr 4, 2014 · 2 comments
Milestone

Comments

@taoneill
Copy link
Contributor

taoneill commented Apr 4, 2014

Some caching helpers were added by @FranckyC and @yohanb in Dyn 2013 while I did the same under another GSoft.Dynamite.Cache namespace. Prefer using the Cache namespace if possible because it evolved to be a bit more generic (and to have one separate cache per security group) during our latest SP2010 project.

@drdeteck drdeteck added this to the v0.5-2013 milestone Apr 4, 2014
@taoneill
Copy link
Contributor Author

taoneill commented Apr 4, 2014

After some initial review by @drdeteck and me, we feel that:

  1. The SessionCacheHelper is slightly misguided: a typical SharePoint install won't have SessionState enabled. Instead, use the normal CacheHelper (i.e. AppCacheHelper) and use a ParametrizedCachedKey with a prefix/parameter determined by the User's identity. After all, the SessionCacheHelper's sole purpose was to keep user-specific values in memory. If the SessionCacheHelper is used for its session lifecycle, we should use the dependency injection feature to target specific lifecycle for our objects.

  2. Everything related to CacheValue was made necessary by the new BinaryClone semantics @yohanb introduced (you can't BinaryClone a primitive value). Originally (and in Dynamite-2010 still), objects fetched from cache are mutable (i.e. they are NOT cloned or deserialized when fetched from cache) and the mechanism supports primitive values. Thus, to keep the model as simple as possible and to encourage memory sharing (always copying/cloning objects as they get fetched from cache gets expensive), all cloning when fetching from cache should be done OUTSIDE of the cache helper mechanism. The cache helper's responsibility should be to hold primitive values or object references ONLY. I.E. it should be possible to fetch an object reference from cache and to mutate that object (and if you do mutate that object, be sure to use proper locking/critical sections to support concurrent access and modification).

  3. The SET method was introduced to the CAcheHelper simply to get around the cloning. As mentioned above, objects fetched from cache should be mutable, so only CacheHelper.GET should be possible, to keep the programming model as simple as possible.

@drdeteck drdeteck modified the milestone: v0.5-2013 Apr 4, 2014
@taoneill
Copy link
Contributor Author

taoneill commented Apr 4, 2014

We added [Obsolete] attributes everywhere in the GSoft.Dynamite.Caching namespace. We'll make a release for @FranckyC and @yohanb with those utilities still there, but they'll be gone in favor of the simpler GSoft.Dynamite.Cache namespace utils by the subsequent release.

@taoneill taoneill modified the milestone: v0.5-2013 Apr 4, 2014
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants