cache/session/application, do these share memory?

[codefragment]

Hi
I understand there are different places to store session info. I'm
only concerned with inproc.

(1) Do the cache, session and application objects store their
information in the same place? I gather theres a limit of 60% of
physical memory that can be used before recycling but is that shared
between them?
In my head you have to keep session info. Cache info (which is
something I've never really played with) is info
that can be thrown away as you can regenerate it, so it doesn't make
sense to me that the application could restart and session discarded
because of excessive cache use.

(2) Any good articles out there on architectural patterns for large
scale/web farmed scenarios. What I'm ideally after is something that
discusses how the session/application/cache objects should be used in
practice. Saying, "use these minimally" doesn't help me a lot.

(3) Last thing, can you use the static keyword in asp.net? I thought
you couldn't and was surprised to see its use advocated over the
application object, not that i'm sure how either would be used for a
web farm.

thanks for any help

 

[Hans Kesting]

(e-mail address removed) brought next idea :

Hi
I understand there are different places to store session info. I'm
only concerned with inproc.

(1) Do the cache, session and application objects store their
information in the same place? I gather theres a limit of 60% of
physical memory that can be used before recycling but is that shared
between them?
In my head you have to keep session info. Cache info (which is
something I've never really played with) is info
that can be thrown away as you can regenerate it, so it doesn't make
sense to me that the application could restart and session discarded
because of excessive cache use.

(2) Any good articles out there on architectural patterns for large
scale/web farmed scenarios. What I'm ideally after is something that
discusses how the session/application/cache objects should be used in
practice. Saying, "use these minimally" doesn't help me a lot.

(3) Last thing, can you use the static keyword in asp.net? I thought
you couldn't and was surprised to see its use advocated over the
application object, not that i'm sure how either would be used for a
web farm.

thanks for any help

Session could use SqlServer or a StateServer (which can be used in a
garden/farm scenario), Cache and Application use only server memory.

There is a difference:
Session is user-specific.
Cache and Application are application-wide.

Cache can throw out objects that are used infrequently (when memory
gets low) or based on other criteria, Application can not.

You *can* use static variables in an asp.net application, but the
values are application-wide, so do not store user-specific data in a
static variable.

Hans Kesting

 

[codefragment]

Session could use SqlServer or a StateServer (which can be used in a

garden/farm scenario), Cache and Application use only server memory.

as I say, for this question I'm only interested in inproc use

I accept all the comments about the different scenarios and where they
are used, but here the question is purely about
recycling and memory use as the cache/session/application grow in size

You *can* use static variables in an asp.net application, but the
values are application-wide, so do not store user-specific data in a
static variable.

So what happens with the statics (and application) objects in web farm
situations? I would guess
the application objects could be shared somehow (?) but the statics
couldn't?

 

[bruce barker]

yes, the cache, session and application objects are all in the same memory.
they are all just static collections.

caches by definination, can be purged, so cache size is not an issue. inproc
session and application are an issue. if they grow too large a recycle will
be performed, which will empty both. you shoudl code your application object
use to recover from a recycle (they will happen for idle time also).

inproc sessions are an issue. they will get cleared on a recycle (file
change, idle timeout, etc). you can treat your session like a cache if you
can recover it.

in web farms there is no sharing of these. each server has its own cache,
application object and inproc session. asp.net currently supplies no sync
services for these caches unless database backed (but somewhat limited).

to use inproc session on a web farm, you will need use the session as a
cache (may or may not be there) or use server affienty (the client always
uses the server server of the farm - a feature of your chosen load balancer).
in general you should never use inproc sessions with a farm or garden.

statics are fine if you want to share the data between requests, just use
proper locking. static methods are no issue.

-- bruce (sqlwork.com)

 

[Hans Kesting]

as I say, for this question I'm only interested in inproc use

I accept all the comments about the different scenarios and where they
are used, but here the question is purely about
recycling and memory use as the cache/session/application grow in size

Only Cache has a mechanism to manage it's memory footprint. The rest
will keep whatever is stored until the application recycles, possibly
due to memory problems.
Although session objects will be cleared when the session ends (which
is 20 minutes (or whatever is set) after the last page was requested).

So what happens with the statics (and application) objects in web farm
situations? I would guess
the application objects could be shared somehow (?) but the statics
couldn't?

Of the options only Session can be shared in a web farm. But not in an
inproc configuration, you need SqlServer or StateServer then. The
others are application-specific.

Hans Kesting

 

[codefragment]

yes, the cache, session and application objects are all in the same memory.

they are all just static collections.

caches by definination, can be purged, so cache size is not an issue.

so I guess the only implication here is that if your close to running
out of memory then
your caching will probably be inefficient or negible as there will be
no memory left in
which to cache.

The statement I guess I was fishing for was:

The process will never recycle due to caching

statics are fine if you want to share the data between requests, just use
proper locking. static methods are no issue.

so I just have to bear in mind that the application object won't be
shared in a session afinity
web farm situation. In essence the application acts like a cache in
these circumstances.

This makes sense to me now, thanks to all for their advice