The session cache stores every user's data set separately on the server. There are many advantages to using the session cache, including:
• Ability to increase speed and gain performance
The session cache is most beneficial when it is used in Memory storage mode. In this mode, the whole data set object is stored in memory in a ready filled state, so it is immediately reused on postbacks and does not need to be filled with data. The performance gain from using this mode can be dramatic, since no data is copied, even in memory, on saving the data set, and there is virtually no delay for data retrieval. However, Memory storage mode has some drawbacks. It consumes server memory. Also, the immediate, without copying data, storage and retrieval in Memory mode take effect only if you configure your application for in-process mode (use SessionStateMode = InProc).
In other session state modes, SqlServer and StateServer, the data is first copied to a persistent object in memory, which is also fast, depending on the data size. If you consider using the session cache to improve performance, weigh it against the possibility of users' data taking up too much server memory. To conserve server memory, you can use File storage mode with session cache. This mode is not as fast as Memory, but it is still about two times faster than the global cache. If you want greater scalability and do not want to allocate server resources for individual users, consider using the global cache or combine session or global cache with memory-resident table views.
• Ability to store data separately
Another possible reason for using the session cache is when it is important that each user's data are stored separately on the server so they are completely insulated from other users' changes. If you make a decision to use session cache for that reason, make sure you really need complete isolation from other users' changes, which in effect means creating a snapshot of data for every user. It is often not necessary and even undesirable to work with such snapshots. Using the global cache might be a better option because it ensures that once you modify a row, it won't change, and unmodified rows changing in accordance with database changes is often acceptable and indeed desirable. Still, if you really need snapshots, use the session cache.
• Ability to effectively store modified data
Also, the session cache can be recommended if a considerable part of the data in the data set, say 50%, is expected to be modified by the user. In this case, the session cache is preferable because it stores modified data as efficiently as unmodified, whereas the global cache stores data modifications separately for each user (thus consuming server resources for this purpose no less than session cache does) and furthermore, the global cache performs special actions on each modified row restoring the data set on postback. This is not a performance drain if modified rows are relatively few, but it becomes essential if they constitute a considerable part of the overall row count.
Unlike the global cache, the session cache is never used automatically. You call SaveData to store data in session cache and Fill to retrieve data from the session cache.
As with global cache, you can make one or more table views memory-resident and store the rest in the session cache. You can also store some data sets in the global cache, some in the session cache, and make others not cacheable.
|
