[Building Sakai] ContentHosting cache?

[Aaron Zeckoski]

As a general thought (only barely related), session type caching is
risky because of issues like what Jim mentioned. Usually, the session
(and session caches) is not accessible to services (as sessions are
normally only accessible to the user they are associated with or
security reasons) and therefore cannot be purged when data changes.

Request based caches are normally pretty safe as long as they are
being purged between requests (hibernate, for example, does a lot of
request based caching in the hibernate Session - depending on how the
transaction wrappers are setup). We should probably make sure that
threadlocals are purged on each request start to make sure they are
not being misused. This is probably not something we can just to as a
blanket operation without looking at how they are being used in each
case.

It might be worth writing down a best practice or two for request and
session caching. I have stuff in a conference presentation from 2007
which I could cleanup and add to the wiki if people generally agree
with the thoughts above.

-AZ


On Sun, Aug 15, 2010 at 10:14 AM, Jim Eng <jimeng at umich.edu> wrote:
> That cache had some problems, as I recall, and was not being used by the time I worked on CHS issues.  But I can't tell you what the problems were.
>
> CHS does a lot of thread-local caching (or did when I last looked) of data relevant to processing the user's current request.  It also saves too much info in session state, which has the effect of caching info for a specific user across requests.  As with many things in Sakai, the permissions and volatility of data make caching difficult.  CHS needs to answer questions for different users in different ways depending on the specific users' permissions, group membership, etc.  And inappropriate caching (as in session state) can result in a user being denied access to resources when permissions or availability change.  I suspect some of these issues may have come up with that early attempt at caching in CHS.
>
> I'm just saying it's not as easy as turning on caching.
>
> Jim
>
>
> On Aug 15, 2010, at 4:39 AM, David Horwitz wrote:
>
>>  Hi All,
>>
>> While reviewing our production cache performance and pondering where
>> Sakai migh benefit from more caches I discovered that ContentHosting has
>> a cache but that its switched off by default.  I can't seem to find any
>> documentation on this cache and wonder if there is a reason why it
>> shouldn't be switched on?
>>
>> For the record it can be switched on with:
>>
>> caching at org.sakaiproject.content.api.ContentHostingService=true
>>
>>
>> Regards
>>
>> David
>> _______________________________________________
>> sakai-dev mailing list
>> sakai-dev at collab.sakaiproject.org
>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>
>> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
>>
>>
>
> _______________________________________________
> sakai-dev mailing list
> sakai-dev at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>
> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
>



-- 
Aaron Zeckoski - Software Engineer - http://tinyurl.com/azprofile