user2954612
user2954612

Reputation: 23

best alternative to cookie,when size limitation kicks in

I have been working with a fairly huge database. I want to populate the webcontrols(dropdownlists) of the page during pageload event to give the webpage as much flexibility as possible. For example, I have a dropdownlist ,that user can select, which will be populated from the unique rows of a specific column of a datatable.

Now, i don't want to fire the oracle query each time page load happens because that will slow down the webpage significantly (about 1mins each time). So i started to think of cookies as solution. I soon found out that limitation of cookie size (4kb) is way too small for my purpose. I will need around 10-15kb of size if i really want to store the datarows locally! So I tried to search if there were any way to increase the cookie size limitation to accommodate my needs and I found the possible solution is localstorage.

  1. Is there really a way to increase the cookie size limitation?
  2. What is the simplest alternative? is it really localstorage? or are there anything else to look into?

details: I am using C#/ASP.NET + ORACLE

Upvotes: 0

Views: 3386

Answers (3)

Win
Win

Reputation: 62290

Here are all storage options for state information in ASP.Net -

  • Cache - a memory pool stored on the server and shared across users
  • Session - stored on the server and unique for each user
  • Cookies - stored on the client and passed with each HTTP request to the server
  • QueryString - passed as part of the complete URL string
  • Context.Items - HttpContext and lasts only the lifetime of that request
  • Profile - stored in a database and maintains information across multiple sessions

Now, i don't want to fire the oracle query each time page load happens because that will slow down the webpage significantly (about 1mins each time).

You have two options for your scenarion -

  • If data shared across users, use Cache
  • If data is unique for each users, use Session

Ideally, you do not want to store in ViewState it will make your page very heavy unless you configure to store ViewState in Sql Server (which is out of the scope of this question).

Update:

localStorage - Not all browsers can handle localStorage, so make sure you check it first.

<script type="text/javascript">
   if(window.localStorage)  {
      window.localStorage.SetItem('keyName','valueToUse');
      // OR
      window.localStorage.keyName = 'valueToUse';
   }
</script>

FYI: ASP.NET does not offer specific methods for handling local storage; you can only manipulate at client side via javascript.

Upvotes: 4

Joel
Joel

Reputation: 2257

You don't want to use cookies for this purpose. There's not only the size limitation, but that cookie is sent back and forth with every request to the server, which could potentially reduce responsiveness in your application depending on your server and user's bandwidth.

Another alternative is to use the Viewstate which stores the data on the page itself. This doesn't have the space limitation, but it does have the same problem as cookies with the increased request size.

You can also use Session which will store the data in memory on the server for each session. This reduces bandwidth requirements, but does take up additional memory space on the server itself, which may not be desirable. Tons of data in memory + tons of sessions could = insufficient memory.

So figure out what your particular tradeoffs are. Viewstate is the most similar to your current solution.

To access viewstate or session in your page, just do Viewstate['KEY'] or Session['KEY']

Another thing to note is that the Session data is persisted for the entire session and across page loads/redirects/etc. Viewstate is ONLY available for that page. If you go to another page, Viewstate is discarded.

If you data is the same for all users, then you could also use Cache, which stores the data at the Application level instead of session. This still takes up memory space on the server, but will not increase as sessions do (a mere 15k in your case!). You can also specify expiration for the cache (either sliding or absolute), which allows you to automatically free up the memory being used if that resource isn't being accessed for a certain amount of time. Just make sure you always check if the data is in the cache before using it as .NET will discard the information if it expires OR if it just needs to clean up memory for some other purpose.

Upvotes: 0

Randy Minder
Randy Minder

Reputation: 48482

You don't want to use cookies.

I had a similar requirement in an application I've been working on. I needed to let a user select a value from ~15,000 choices using an autocomplete input box. I did not want to hit the database each time the component needed to find a value. I decided to use session storage to store all possible values and then feed those values to the autocomplete component. It works great. You could also use local storage.

For my needs, session storage was a better choice because I didn't need to values to persist after the user closed the browser tab. Also, before I store the 15,000 items in session storage, I compress them, using JavaScript compression, to save space. I'm using lz-string for my compression.

Upvotes: 0

Related Questions