if not to use session variables then what RRS feed

  • Question

  • Hi Everybody,

    I have question which comes to mind of nearly everybody who is designing a webapplication in .net.

    I wish to store some user related data across the webpages in a Asp.net website.

    Since the data is big, i don't wish to use session variables to store that.

    So where should i store it?One thing i want to make clear here that i don;t want to use cookies(now i think i am becoming too selfish :) ).

    Somebody told me of making a class static but i don't know whether it is a feasible solution for a webapplication.IF somebody knows about this ,kindly let me know with some code for direction.

    Some other people say that we should persist the class which is holding the data.I don't know how to do it, might be by serializing and moreover i think this will decrease the performance of applcation by introducing latency for data retrieval and storage.

    Some people talks about putting it in a hashtable ,making its viewstate to true and make enableviewstatemac of every webpage to false.In this way we can retrieve the hastable from viewstate in every page of wwebsite.I myself am not sure of this approach as it puts everything on the client's webpage though in encrypted form.I am also not clear about whether viewstate takes memory of server or client(might be client as it increases the webpage content).I am also not sure about of whether session or viewstate is faster for retrieval and storage.

    I ask you all architects to please guide me about what would be the best way to do it with some example code if possible.



    Thursday, July 27, 2006 5:53 AM

All replies

  • Hi Leo,

    Do consider UIP application block as well.

    Its true that apart from UIP application block, there seems to be no clean solution provided in ASP.NET to manage state across pages. Like

    - Viewstate is for the same page

    - Session data is fine but has two problems a) If you want distributed sessions in a cluster, you have to watch the session size b) if you want to support multiple "windows" on the same session ( ctrl-n on IE) you are in trouble.

    - Static / hashtable is like session with an added problem of having to clean it up. There are however ways to make the hashtable overcome the session ctrl-n problem by composing the cache key with the user inputs.

    Traditionally ( coming from the days when ASP sessions were considered unreliable and we had custom session based on cookies ), I have preferred the static / hashtable option. My implementations would go something like this

    1) A static hashtable will store data, an "index" dataset or enumerable object will store expiry parameters for the hashtable

    2)The pages are coded to handle the scenario IF the donot get anything from the hashtable. (This is me being anal about session failover and for handling Ctrl-N s). Essentially this means hidden variables to store all User Inputs - which can be used to re-create the current state from scratch - just in case!!.

    3) Background threads doing a cleanup of cache - On session expiry event and on the cache timeouts/expiry the developer choses .

    This kind of approach is not very difficult to implement if the state of the application doesnot last beyond a 5-7 page flow, at the end of which, the state doesnot depend on user inputs. This approach might become exponentially more complicated as the complexity of the application flow grows.



    Thursday, July 27, 2006 9:26 AM
  • Did you consider using sql session data provider ?If the object is serializable ASP.Net takes care of storing the data  to sql and retireving back . My question is ,why do you want to maintain that much big data in session?

     Can you just store the key (id) in the session and retrieve from database?

    If you use viewstate, it will increase the network bandwidth usage drastically and the performance will go down. You can use it for small amount of data , not for big one.

    Ctrl+N is by design, it will share the same session on the new window. I don't think it is a potential issue for a user.


    Tuesday, August 29, 2006 5:04 PM
  • You may consider the use of the CAB - Caching Application Block

    Common Scenarios

    The Caching Application Block is suitable for any of the following situations:

    • You must repeatedly access static data or data that rarely changes.
    • Data access is expensive in terms of creation, access, or transportation.
    • Data must always be available, even when the source, such as a server, is not available.

    The Caching Application Block can be used with any of the following application types:

    • Windows Forms
    • Console
    • Windows Service
    • Enterprise Services
    • ASP.NET Web application or Web service if you need features that are not included in the ASP.NET cache

    The Caching Application Block should be deployed in a single application domain. Each application domain can have one or multiple caches, either with or without backing store(s). Caches cannot be shared among different application domains.

    The Caching Application Block is optimized for performance and is both thread safe and exception safe. You can extend it to include your own expiration policies and your own backing store.




    Tuesday, August 29, 2006 6:14 PM
  • if the values to be gloabal to all users , you can use cache.

    Also, when asp.net manages session(over db), why would you create expiration policies and run a cleanup background task? I don't  think that will be scalable.

    Tuesday, August 29, 2006 9:41 PM