Programming cachelss applications

by Mike Levin SEO & Datamaster, 07/18/2005

Don’t cache anything anywhere, unless it’s an Application value. This precludes the use of any sort of per-user Session persistence or even any techniques that cause the use of temporary tables on SQL servers. Interestingly, this includes anything that causes what might create what we sometimes call RecordSets and cursors – fundamental to Web development. The reliance on cursors, tools like ADO (Active Data Object), and anything that caches results, is a handicap to implementing scalable apps capable of threatening the Enterprise space. Try building an app that lets you browse a table with millions of records where the data underneath is changing in real time, and allow it to be accessed by thousands of simultaneous users. Try to serve it all off of one webserver and one database server, and you will see what I mean. Anything that causes data to be cached per user, whether the caching is on the webserver or the database server, will kill application performance, and prevent it from being viable as an enterprise-wide solution. Any connection to databases for displaying data should be read-only, forward-only connections (known as fire hose mode). And you should never query for any more data than you plan to display instantly on the screen at that moment. The combination of fire hose mode with querying for only one screen-full of data at a time effectively makes SQL fire-and-forget, just like original webservers were designed to do. Yes, I am advocating living without any sort of server-side session maintenance, so that applications can have stunningly fast performance, and scale beyond the imaginable limits of a single set of servers.

Next topic: So, why cache Application values? Because your apps should be programmed so there are a finite set of application values that can be produced – as opposed to Session values, which could be from an infinite potential set of users.