Blob Caching and Web Gardens

I've had a case open for a long time in regards to blob caching not functioning properly under MOSS SP1.   Why SP1?  Because we only noticed the problem occuring after SP1 was installed, and the header information (see an earlier post) appeared to indicate that post-SP1 the problems were occuring.

One of the really switched on Australian escalation engineers, who doesn't even specialise in sharepoint, cottoned onto this and figured out that blob caching will not work with web gardens. 

Once you actually know this, its easy to google or livesearch for "blob caching web garden" and find a couple of items, including a technet article on why this happens.

Web garden settings

Web garden settings can also inadvertently cause the BLOB cache to work inconsistently. Because only one process can acquire the lock necessary to manage the cache, successful use the cache depends on which thread services a request. If a Web garden that does not have the BLOB cache lock services a request, the content it sends in response will not have caching directives associated with it. That increases both the number of requests and the amount of the data sent over the network. Therefore, if you intend to use the BLOB cache, you should not use Web gardens.

So now theres a bit of a trade off.  Do you want to have multiple worker processes serving your content?  or would you rather cache your large objects on your local filesystem instead of retrieving them from an SQL server repeatedly?  Thats not going to be easy to answer and its really going to depend on the situation.  I'd suggest if your backend is the bottleneck to your farm, then blob caching would be the most valueable.

Locking down your custom sharepoint code

This might be truely obvious to anyone who is a web developer or an application developer, I'm neither of those.   I recently created a set of custom web parts to administer user access on a hosted MOSS solution, and one of the challenges I have just come across was locking these pages down so that only administrators could use them.

The first one was pretty easy : Only display the actual link in site settings if you are an administrator :

  <CustomAction
    Id="CreateUser"
    GroupId="UsersAndPermissions"
    Location="Microsoft.SharePoint.SiteSettings"
    RequireSiteAdministrator="TRUE"
    Sequence="50"
    Title="Create User">
    <UrlAction
      Url="_layouts/CreateUser.aspx" />
  </CustomAction>

While this hides the menu link, it you know the URL you can still access it without appropriate permissions.  Finding an answer to this was more challenging and when I eventually did find it, it wasn't really the fix I wanted – but it works.

public class ApplicationPage3 : LayoutsPageBase {
    protected override bool RequireSiteAdministrator
        { get { return true; }
    }

    protected override void OnLoad(EventArgs e) {
       // Your code goes here 
    }
}

This (to the non coders) will check to see if the user accessing the page is a Site Administrator.  If Not, they get a standard access denied splash page.  If they are, the code in the // Your code goes here area will be run happily.

Both of these little gems can be found here – http://msdn2.microsoft.com/en-us/library/bb892187.aspx – and I really hope that this saves someone else the amount of time I spent looking for it.