Application object = available to all users  always
Cache object = available to all users, but will expire at some point
Sessions = available to 1 user, will expire after 20 minutes of inactivity by default

http://aspng.com/quickstart/aspplus/doc/datacaching.aspx
has what you want to know about dependencies in cache.

2. This one is about caching pages, so if we enable  caching for a page  using outputcache directive   , are the pages  suppplied from cache  contain static information  or the page will go through the page init, page load  and other phase  again. Can you guide  me to any good  link where this is more detailed.


Basically with OutputCache, the UserControl or Page code only runs for first user  that hits the page/uc.

Think of it this way, I hit a page or UC with a 10 minute cache at 9:01am 30 secs

u1 9:00am 30 secs 10ms => run code => generate HTML
u2 9:00am 30 secs 15ms => USE same HTML we generated for User1
u3 9:00am 31 secs 2ms => USE same HTML we generated for User1

So don't expect to see page_init, page_load, or even an instance of the UserControl object or page after user1. Thus properties or other aspects of the UserControl cannot be interacted with. Run the code @:
http://www.learnasp.com/students/charlescarroll/sourcecode-searcheruc_cached.aspx
for a UserControl that is cached and "blows up" after subsequent calls.

http://www.learnasp.com/students/charlescarroll/sourcecode-searcheruc_cached_fixed.aspx
shows my answer in this case. What I wanted (the city, state or zip selection) could be alternatively be pulled out of the request collection in that case.

The part that makes page and fragment/uc caching so powerful is VaryByParam. Lets say we make a jobsearchesults.aspx that is feed inputs jobcategory, city, state, zip from a form. The above model just is not workable, we could not give the people below who supply different inputs the same HTML....

user1 =>
category=ski instructor
state=Utah

user2 =>
category=Programmer
city=Dallas

user3 =>
category=Teacher
city=Atlanta
st=GA

user4
category=Programmer
city=Dallas

<%@ OutputCache Duration="300" VaryByParam="jobcategory;city;state;zip" %>

u1   9:00am 30 secs  10ms          => run code => generate HTML cache
                                                                         tied to "ski instructor/Utah" 
                                                                         expires 9:05am 30 secs 10ms
u2   9:02am 10 secs  15ms         => run code => generate HTML cache
                                                                         tied to "programmer/Dallas" 
                                                                         expires 9:07am 10 secs 15ms
u3   9:03am 31 secs  2ms          => run code =>  generate HTML cache
                                                                         tied to "teacher/Atlanta" 
                                                                         expires 9:08am 31 secs 2ms
u4   9:03am  35secs  0ms                             =>  use HTML cache
                                                                          tied to "programmer/Dallas" 

You can vary by browser as well or any HTTP header. This would allow caches also created for different browsers combinations to be maintained independently.

The beauty of this is two-fold:
1. ASP.net does all the work for you. You just add VaryBy. They do all the "under the covers" tracking of what caches are created/expired/etc.
2. A lot of people don't realize on a busy site how small durations can improve scalablity. Imagine a stock site or Amazon calling a UC with a 20 second cache. If a page was hit 1,000 times in that duration what used to be 1,000 pieces of code running (database connections opened/closed, XML files read/parsed/transformed) are now just resolved by throwing back HTML like lightning to the requestor.