[sakai2-tcc] Rewriting Site Caching - KNL-89

[csev]

I agree with Aaron that replication is a bridge too far.  Invalidation is perfectly fine - and invalidation of the site object and all its children happens even if a tool property is changed - I think that is a good approach actually - finer grain invalidation on a page or tool level would make things complex and fragile IMO.  

The first step is to remove all the caching code completely - and then test the code.   It was scary with subtle work done in constructors that ultimately made database calls and called other constructors - that might lead to the same code being recursively called on it self.  I think the last time this broke was a concurrent modification exception when a parameter was passed recursively into a constructor and modified inside of a recursive call to itself.

The problem as I recall was the code was rightfully trying to anticipate a series of calls that would load a lot of sites (knowing the list the portal was about to retrieve) and then loading the tools pages, and properties associated with those in a s few SQL queries as possible.  Unlike other cache approaches elsewhere in Sakai, this one does anticipation and lookahead.  

It is a great approach and necessary  - the last thing we need is the first time a user logs in is an n-cubed loop retrieving sites, pages, tools, and properties one at a time.  At that point we might as well use Hibernate :)

But my instinct has always been that complex-look-ahead-cache should not be done in a constructor for an object - but instead as a separate method in the service like SiteService.preWarm(list-of-site-ids) and that would try to do one or three SQL queries and create site+page+tool+property objects and put them all in caches - and then the retrieval of an individual site would check the cache and if it is not there retrieve it in a direct fashion, adding it to the cache without any complex look ahead.  There should be no cache logic in constructors when we are done.

My memory s somewhat vague in all these details - so I just put this out as my recollection as to what the proper way to fix this was based on looking at it years ago.  So this is not a blueprint - for the fix - just something to inform thinking of folks who can spend many solid hours poring over this.

/Chuck