Total Caches

There are two cache types which cache all of the data (you can exclude certain container types if you want).  The summary cache caches all the summary information, the full cache the full record.  The full cache implies holding considerably more data in memory but is faster.  It makes sense up to 500 or 1000 records.

The total caches enable queries to be run across cached data.  This is not possible with the more conventional resource-limited cache.  This allows for things like recirculation to be built very fast on the server.  However, there are a few issues to bear in mind.

One is that while the cache can be kept up to date when changes are made to the database through the editor on that server, that is not possible for direct updates to the database, or changes via other servers.  You can refresh the cache from the database by going to /Lynicon/Admin (when logged in as an Admin) and clicking the Reload button on the row for the cache module.  This can take a while to finish.

Another issue is how Lynicon deals with the periodic recycling of the App pool that is a feature of most IIS installations.  When this is done, Lynicon writes the cache serialized to a binary file, and when it starts up Lynicon reads this data back in again if it is available.  Certain kinds of shutdown will not trigger this dumping of the cache data, particularly when you are working on IIS Express and you stop the server via Visual Studio.  Also, it is possible when rebooting a server that Lynicon will not have time to write the binary file in which case it can get corrupted.  In these cases, you can manually save the cache by going to /Lynicon/Admin and clicking the Save to File button by the cache module.

Binary caching can cause issues when types are updated.  The reload will fail if a type definition has been changed in certain ways since the serialized file was saved.  In this case, Lynicon will reload all the data from the database, which can sometimes be quite slow.  This is not essentially a problem but during an update of a production server, it is as well to be aware of this danger. It is possible to avoid the issue by on a local up to date development version of the site, pointing the database connection string to the relevant production database and starting the site.  Then go to /lynicon/admin, find the line labelled with the name of the relevant cache, click Reload and when (after some time) this process completes, click Save To File (which will be much quicker).  You then have in App_Data/<cache name> a *.bin file which can be copied into the same location on the server when updating the site, at the point in time where the app pool has been stopped.