Question about Cache object

[pajarokillo]

Hi, i have a questions about Cache object:

1.- the objects that i store in the Cache object, it store in the memory of the server?

2.- How many objects is recommended to store in the Cache object?

3.- What is the difference between the Cache and Session objects?

For now, that's is all friends!!, but i will return

 

[vbkris]

>>it store in the memory of the server?
yes

>>How many objects is recommended to store in the Cache object

depends upon server speed, if the server is in want of memory cache objects are dumped automatically. a cache object can be depended upon for only upto 5 minutes.

>>What is the difference between the Cache and Session objects?
1. Cache is restricted to the page that caches the object while session is through all pages.
2. cache can be dumped (above point) while a session is never dumped...


Known is handfull, Unknown is worldfull

 

[Rhys666]

1 - Yes this is 'in-memory' on the web server

2 - That's gonna depend on the size of those objects

3 - Hmmm, Here's a MS Link for some info which I'll quote from below; MSDN Magazine Article

Global Caching

The ASP and ASP .NET Application object is another data container that can be even more dangerous than Session. Everything that you store there is kept in memory until the application is closed by the last user connected. Of all the information stored in memory, Application is the most persistent. However, if you have relatively constant information to share across the various sessions, and if you can have a reasonable estimation of the size, using Application turns out to be a good bargain. In general, the size of the data, as well as the number of concurrently connected users, is not an issue as long as you know its magnitude in advance and can choose the hardware accordingly. For example, the NASDAQ Web site is built with more than 40 MB of stock information stored in the Application object. As long as the hardware is properly tuned, using the Application object will not be a cause for concern.
In ASP .NET you'll also find that the Cache object provides similar capabilities. Cache is a thread-safe object and does not require you to lock and unlock before reading from or writing to it. In addition, Cache lets you associate a duration as well as a priority and a decay factor with any of the items you store in it. Any cached item expires after the specified number of seconds, thereby freeing up some of the memory. By setting priority and decay of priority, you can control the memory occupation and help the object to control memory for you. Both Application and Cache are globally visible across sessions but don't work in a Web farm scenario. In this case, if Session does not meet your needs, you might want to resort to a custom module that acts as a data container while being globally visible. Web Services certainly provide a good infrastructure to devise and build such made-to-measure components.

The .NET Session Object

In ASP and ASP .NET, the Session object is a global repository for data and objects that belong to the session. The visibility of the data is limited to the pages invoked within the session. Using the Session object is critical however you look at it. It guarantees quick and prompt access to data and ready-to-use objects. On the downside, though, all the session data is duplicated for each active session and each connected user. From this you can easily deduce that applications based extensively on the Session object cannot support uncontrolled and constant growth in the number of users. These considerations hold true in general and apply to .NET as well as to the previous versions of ASP.
Feel free to use Session when you write, test, and demo code, but be extremely careful when it comes to production code. This does not mean, of course, that Microsoft would have been better off dropping the Session object. The amount of data stored in Session must be kept under strict control, but using this object is still the fastest way to deal with session-specific data.
In .NET, the Session object plays the same role as in ASP, but it has two significant enhancements. First, all commonly used objects can now be safely stored in a Session slot. Second, the Session object is the programming interface for a module, the Session Manager, that can work in-process, out-of-process, and can even rely on SQL Server™ for data storage. As a result, the Session object can also be used in Web farm architectures.
In ASP, some flavors of COM objects (typically, objects written with Visual Basic) could cause serious scalability issues when stored to Session. This is due to the threading model employed by Visual Basic COM components, which forces a given component to be manipulated only by the thread that created it. Since Internet Information Services (IIS) uses a pool of threads, there is nothing that can guarantee that a request involving a living instance of a Visual Basic COM object is served by the same thread. If this is not the case, the request is delayed until the right thread is available. Don Box explained this topic in the House of COM column in the September 1998 MSJ.
This scalability issue has been solved in .NET as all .NET objects are thread-safe and can be managed by any member of the IIS thread pool. So, as long as the size of the data is not an issue, you can save any live .NET object in a Session slot.

Rhys
"There are some oddities in the perspective with which we see the world. The fact that we live at the bottom of a deep gravity well, on the surface of a gas-covered planet going around a nuclear fireball 90 million miles away and think this to be normal is obviously some indication of how skewed our perspective tends to be"
DOUGLAS AD