Has Site Cache File (site.cache) been depreciated in v3.5?

Permanently deleted user

October 20, 2011 22:14

Hi,

I'm yet to see a site.cache file appear in 3.5?  Has the site.cache architecture been dropped & if so is there anything we need to be aware of w.r.t. a site caching itself somewhere else or in some other form?

Brad

0

• 

  Permanently deleted user

  October 20, 2011 22:28

  I believe the site cache location has been moved to a new location I have been looking over some items and noticed the same thing. I found a new site cache location that stores xml files so it appears this has changed. I posted the path below

   

  C:\Program Files\Latitude Geographics\Geocortex Essentials\[YourInstance]\REST Elements\REST\App_Data\SiteCache

  0
• 

  Ryan Cooney

  October 20, 2011 23:00

  The concept still exists, but the implementation has changed.

  At 3.4.x Manager was responsible for creating Site.cache files when it saved or reloaded sites. This was done to provide significant start-up time improvements. It had some drawbacks though. Most notably, only Manager could create them. If you edited a Site.xml directly it wouldn’t invalidate the Site.cache file, so you’d have to go delete it manually, make your edit, then use Manager to create a new cache.

  We’ve made the following changes at 3.5:

  • Manager no longer creates the Site.cache files.
  • Each instance of Essentials will create and hold onto its own cached sites (C:\Program Files\Latitude Geographics\Geocortex Essentials\[YourInstance]\REST Elements\REST\App_Data\SiteCache).
  • The cache file contains additional metadata about when the cache was created so that we can determine if it is still valid.

  This mechanism is faster and we are able to eliminate the need for manual steps to clear the cache.

  This didn’t make it into the 3.5 Admin Guide, but it will be there in the next maintenance release.

  --Ryan

  0
• 

  Permanently deleted user

  October 20, 2011 23:17

  Thanks Ryan for the info.

  So i'm assuming it now just create *.xml files in this location?

  A reason for asking this question was i saw some inconsistencies between my test / prod but i'm about to answer my own question i think.  I noted on the security permissions for this folder i don't have write access  (when running under another app identity (e.g. networkservice user)) and hence files have not been created.  Will implement change & i'm confident this resolve issue.

   

   

  Cheers

  Brad

  0
• 

  Permanently deleted user

  October 20, 2011 23:26

  Ryan,

  Sorry obvious question - when is this file created/updated (e.g. if i edit the site.xml manually, one can presume i need to clear the cache file as well)? 

  Brad

  0
• 

  Ryan Cooney

  October 20, 2011 23:44

  Hi Brad,

  1. When a request comes in for a site Essentials will look to see if it has a SiteID.xml cache file.
  2. If a cache exists it compares the date of the cache and the date of the actual Site.xml.
     1. If the cache is up-to-date it will use it.
  3. If the cache did not exist or it is out of date Essentials will deserialize the site from the Site.xml.
     1. Essentials creates a new SiteID.xml cache.

   

  Any edit to a Site.xml will automatically invalidate the cache. You should not need to manually delete the cache files.

  In a default installation the Essentials user will already have write permissions on the App_Data folder, but if you've changed users then you will need to ensure that the user has access. 

  --Ryan

  0
• 

  Ryan Cooney

  October 21, 2011 00:43

  Minor correction. This is documented in section 5.2 of the Rest Administrator Guide.

  --Ryan

  0

Please sign in to leave a comment.