An Async Html cache – Part I - Writing the cache

An Async Html cache – part II – Testing the cache

Luca Bolognese's WebLog — Fri, 08 May 2009 18:53:22 GMT

Other posts: Part I – Writing the cache Let’s try out our little cache. First I want to write a synchronous

Luca Bolognese on HTML caching in VB.NET (Lisa Feigenbaum)

The Visual Basic Team — Wed, 29 Apr 2009 22:15:28 GMT

You may know Luca Bolognese from his well-known work on C# LINQ. Luca is now the Group Program Manager

async

Greg — Wed, 29 Apr 2009 22:11:51 GMT

The idea of wrapping the asychronous cache handler in a class is to reduce or eliminate the need for callers to bbe asychronous. This makes coding the caller's class much easier.

The other aspect is that the amount of work done in an asychronous call back should be minimal since you don't know when it will be executed. For example, you get a callback call with the HTML you need whilst you are destroying the caller's object. This is more important when dealing with large amounts of data in each cach entry (e.g., large xml strings) since processing each cache entry may take considerable time.

re: An Async Html cache – part I

lucabol — Wed, 29 Apr 2009 20:39:11 GMT

Thanks Greg, these are good comments.

We have a different design goal though. Both solutions are valid. I want the method requesting the URL to have the flexibility of deciding what to do (aka have a callback). I do want the exposed API to be async.

The rest of your comments talk to the difference between writing production code and a conceptual example. I'm doing the latter here.

Simpler method

Greg — Wed, 29 Apr 2009 20:20:09 GMT

It would be much easier to use a normal thread safe collection class.

Each element would have:

key

url (string)

status (loaded, failed, waiting to load, partially loaded)

last status change (date/time)

html_loaded (string)

last_referenced (date/time)

can_timeout_and_be_deleted(boolean)

Class methods

Get HTML from URL(boolean lookup_only = false, int max_block_seconds = 0 /* -1 block forever, 0 - don't block, otherwise block for X seconds*/)

Get HTML from KEY(boolean lookup_only = false)

Delete_entry(URL)

Delete_entry(KEY)

A thread or threads internal to the class would load the html asychronously and be invoked via a clock timer with ticks a few seconds apart.

Attaching a callback for each request is much harder to implement. It is upto the method requesting the URL to decide whether or not it blocks, needs an asychronous callback/interrupt or polls for data.

The idea is that for nearly all cases, no new threads should be created and no new callbacks should be hooked up. This keeps your code easier to understand and debug. Common faults and scenarios are handled easily:

- requesting thread terminates

- asynchronous load times out

- error loading html

- html hasn't been used for 5 minutes and can be removed (a tunable cache parameter)

- memory limit of cache reached and unreferenced html strings can be removed (a tunable cache parameter)

- duplicate request for a URL/KEY from more than one thread

- html can be loaded from multiple sources (web, file, network share, ftp, database, etc.).

- html load failed as html string exceeds the size limit on loaded string (e.g., a tunable cache parameter)

- The common problem with attempting a callback for a method that is terminated is avoided. That's a problem when the callback requires the cache to build a complex packet of data to pass in the callback.

This is quite similar to basic page handling algorithm in a virtual memory system (circa 1980). It's how one handled this in systems lacking real threading or with non-reentrant GUI message handling (VB6 GUI/MFC GUI posting a message to the current winform indiciating asynchronous request completed).

An Async Html cache ??? part I | ASP NET Hosting

An Async Html cache ??? part I | ASP NET Hosting — Tue, 28 Apr 2009 03:27:49 GMT

PingBack from http://asp-net-hosting.simplynetdev.com/an-async-html-cache-%e2%80%93-part-i/