Update Dec 2010: See this post for details of important changes since this post for first published.
Session state lost after publishing.
This post follows on from Part 1.
The symptom:
I guess this is pretty self-explanitory, but it depends how you are arriving at this problem. You might be using real accounts, virtual users, or whatever. The effect is that your extranet user, i.e. public website user, appears to lose their session some time after logging in. They are effectively logged-out. You won’t notice this with anonymous users, only users that have logged in. This may also initially appear as a security problem, perhaps the user is suddenly unable to access content they should have access to.
The problem:
Pretty much the same as in Part 1. If the Sitecore staging module is set to the recommended “Full” cache clearing mode, and a publishing operation occurs, all extranet users are logged off after the staging module .xml work files are processed. As explained previously, there is a short delay between the publishing operation starting and the web service actually being called from the master.
The cause:
When the Sitecore staging module is set to the recommended “Full” cache clearing mode, the slave server clears all caches simultaneously, but it also calls Context.ClientData.RemoveAll() which effectively clears the session for extranet users. This affects the current available version of the staging module for Sitecore 6 as of July 2009 (v5.4.0 rev 080625). In contrast, the current version for sitecore 5 has been fixed as of July 17th, and should no longer have this issue.
The solution:
The staging mode in “partial” cache clearing mode does not invoke Context.ClientData.RemoveAll(), so the simple solution is to use the “partial” cache setting. Again the problem is as stated before – this is not the recommended setting, and this is reiterated in the troubleshooting section. There is also no explanation of the scenarios where partial cache clearing is not enough, just that in the “partial setting does not clear the entire item cache”. I had previously thought that this would affect publishing operations that include template changes, but I haven’t explored that notion further.
Finally, despite this rather large bug being known, it is not documented at all other than in forum posts. Nor is it in the release notes. A slightly similar but unrelated issue (almost certainly less common too) is covered in point 6.2.3 of the installation document.
This is a serious problem (and design flaw!) because publishing during the day of important information (like document links) will logout all active users. Partial clearing the cache doesn’t do anything meaning it is useless. Links are simply not updated to new documents. For non-technical users it is just a mystery.
It’s a serious design flaw in how caching is done. Cache is simply to speed up but it must be able to flush without a problem. Definitely the simple content pages with just some links. Flushing sessions is about process data and not about contents. Hopefully this is fixed soon because is makes content unmanageable.