mca blog

while i was reviewing code this evening to prepare for additional refactoring, i discovered a *big* hole in my caching pattern. my FileHandler and SqlXmlHandler classes do a good job of checking for sending a 304 Not Modified status to the client. but when the 304 is invalid, the classes fail to try to send a copy of the cached item itself when possible. i failed to see that since most often i was seeing 304 results. but, during testing today, i noticed the problem. now that it's fixed, i should see some additional responsiveness for large/complex resource objects.

also, i was able to refactor the code that handles both the Not-Modified and 'deliver from cache' situations. basically, moved this code into the Cache class (used by all resource classes) and exposed a single method. that allows me to get rid of about twenty lines of code in each of the resource classes.

below is the new line of code along with the old code i can now throw away:

  // use cache, if possible
  if (ch.ResourceExists((Handler)this))
      return;

  // *** old code
  //// retreive from cache, if possible
  //co = ch.GetCacheItem(this.Context);

  //// not modified?
  //if (co != null && ch.Return304(this.Context, co))
  //{
  //    this.EntityTag = co.ETag;
  //    this.Expires = co.Expires;
  //    this.LastModified = co.LastModified;
  //    this.Status = new StatusMessage(HttpStatusCode.NotModified, Constants.cType_Html);
  //    this.Response = null;
  //    return;
  //}

  //// available in cache?
  //if (co != null)
  //{
  //    // use expiration caching
  //    if (co.Expires != DateTime.MinValue)
  //        this.Expires = co.Expires;

  //    // use validation caching
  //    if (this.UseValidationCaching == true)
  //    {
  //        this.EntityTag = co.ETag;
  //        this.LastModified = co.LastModified;
  //    }

  //    this.Response = co.Payload;
  //    return;
  //}
  // ** old code