.Hibri

When going through the asp.net forums, one thing I've noticed is that there is a lack of understanding among many devs about ASP .Net caching. The majority of the problems are caused when trying to use the Cache as a reliable in-memory storage medium. The Cache object is not meant to do this.

Cache storage is volatile, It can be garbage collected, it can expire, and it is not expected to be synched in a web farm.

So far I've used the Cache to avoid expensive db hits. I use a refactoring approach to storing data in the Cache.

First I write my usual data access and data binding code with,

   Datatable userDataTable;
   userDataTable = DataUtils.GetUsers();
   //bind and display

 

Now to cache the user date, I refactor the code to this,

DataTable userDataTable;
userData = Cache["USER_DATA"];
if(userData == null){
	userDataTable = DataUtils.GetUsers();
	//code to refresh cache, insert etc...
	Cache.Insert("USER_DATA",userDataTable);

}

//bind and display

This simple practice ensures that there is always data, and handles a cache miss gracefully. Any thoughts on this ?

nothing to write about. not much happening. I'm graduating with an MSc in IT Consulting in December, just got my results confirming it. It has been a hard year, and I'm relieved that its all over now. I'll be going back to work soon. More details on that later.

VS 2005 is out. Get your hands on it. If you are looking for free copies (like me) MS is giving them away at their launch events. I'm attending the 15th of November event at the Novotel in London.  I'm skipping the ASP .Net sessions on the 14th because I know quite a bit about that already. I'm more interested in the Biztalk, SQL server 2005  and Team suite sessions.

Eid Mubarak to all of you ...

In VS 2003/ASP .Net 1.1 , global resource files (.resx files used by the whole application) compile to thier own assemblies like, assemblyname.resources.dll.

In VS 2005/ASP .Net 2.0 these global resources are kept in the App_GlobalResources directory, and do not compile to individual assemblies. Because of this using the ResourceManager constructor to load the resource assembly does not work in ASP .Net 2.0 because a resource assembly does not exist. .Net 2.0 adds these global resources to their own namespace, and does some runtime magic to load the correct resources.

For example in 2.0, if you have a resource file named myresources.resx, the resource manager object is obtained by

  1 Resources.myresources.ResourceManager

This applies to ASP .Net web applications only, the ResourceManager works in the old way in class library project and WinForm apps.

read more here

I'm doing all this on the RTM version of VS 2005, and its looking very good :)

Niftty feature in 2.0,

this is via http://blogs.msdn.com/dgorti/

In Whidbey (.NET Framework 2.0) System.Net has a new feature called Tracing.
This uses the builtin CLR Tracing functionality. What is interesting about the System.Net Tracing is that
You can easily  see the data that is being sent or received without having to use the NETMON.

If you have used Network Monitor tools like NETMON/Ethereal you will find that
there is so much noise that you need to weed through. This can be partially addressed through
capture filters and display filters. But then looking at a frame in the capture you can't
easily determine which process issued that request. Similarly if there are multiple threads,
you can't easily determine which thread issued that request. One more thing is that if the
client and server are on the same machine you can;t capture the loop back traffic. Perhaps the most limiting of all
is that if the application is using SSL (https or FTP with SSL) then it is not possible to look at the traffic.
You can at most see the TCP frames with encrypted payload. Not much of use. Right?

With System.Net, we addressed all these issues. System.Net tracing is
1) Per process
2) Shows threads
3) Works for SSL
4) Works for Loopback.
5) You don't need to recompile the code

Continued..