Application variables VS Cache objects !!
-
Hi I am using VB.net/ASP.NET and SQL Server 2000 for asp.net application. I am using Country table data several places in my application. For that I am using Application("Country") variable to store its data, so that I can use it anytime. Should I use Cache("Country") instead? With this approache, the problem is if Cache object expires, then I need to make another database server trip, which can be costly affair. Anyway, both stay in server's memory. Please advice which one is better. Thanks in advance. Pankaj
-
Hi I am using VB.net/ASP.NET and SQL Server 2000 for asp.net application. I am using Country table data several places in my application. For that I am using Application("Country") variable to store its data, so that I can use it anytime. Should I use Cache("Country") instead? With this approache, the problem is if Cache object expires, then I need to make another database server trip, which can be costly affair. Anyway, both stay in server's memory. Please advice which one is better. Thanks in advance. Pankaj
If you put something in the cache, you can specify that it never expires. Even if it did expire, how much does it really cost to read it from the database again? Is it that noticeable if it is read once every hour? Every 2 hours? Every 4 hours? Sean Winstead
-
If you put something in the cache, you can specify that it never expires. Even if it did expire, how much does it really cost to read it from the database again? Is it that noticeable if it is read once every hour? Every 2 hours? Every 4 hours? Sean Winstead
-
Thanks for reponse Sean. Though I can read from database again. But, why do I need to? If I have a way to store the information as a long as application runs, then shouldn't I use it? Thanks Pankaj Follow your goals, Means will follow you ---Gandhi---
Though I can read from database again. But, why do I need to? If I have a way to store the information as a long as application runs, then shouldn't I use it? Yes. The point I was trying to make is that it may not be worth worrying about if there is nt that much data to read and it is not read too often. But as I mentioned, you can tell the cache that the data never expires and the point is moot. Sean Winstead
-
Though I can read from database again. But, why do I need to? If I have a way to store the information as a long as application runs, then shouldn't I use it? Yes. The point I was trying to make is that it may not be worth worrying about if there is nt that much data to read and it is not read too often. But as I mentioned, you can tell the cache that the data never expires and the point is moot. Sean Winstead
The whole point of the cache is that even items that have not expired may be scavenged when there is memory pressure. Better to slow down because you have to reread the database and recreate the cached data than to fault completely because an allocation can not be performed. And that's the answer for the original poster as well. Stick your country list in the cache with no expiration but always access it via a method that tries the cache and if it isn't there recreates it from the database and caches it. This gives you multiple advantages: only one piece of code knows how to to create the list from the database; you don't populate the cache till you need to the first time; your application degrades gracelly if memory get's tight; unless you have memory pressure your performance is exactly the same as putting it in application state, i.e. one read from the database all other reads from memory. -- -Blake (com/bcdev/blake)
-
The whole point of the cache is that even items that have not expired may be scavenged when there is memory pressure. Better to slow down because you have to reread the database and recreate the cached data than to fault completely because an allocation can not be performed. And that's the answer for the original poster as well. Stick your country list in the cache with no expiration but always access it via a method that tries the cache and if it isn't there recreates it from the database and caches it. This gives you multiple advantages: only one piece of code knows how to to create the list from the database; you don't populate the cache till you need to the first time; your application degrades gracelly if memory get's tight; unless you have memory pressure your performance is exactly the same as putting it in application state, i.e. one read from the database all other reads from memory. -- -Blake (com/bcdev/blake)
Good point. Sean Winstead
-
Good point. Sean Winstead
-
The whole point of the cache is that even items that have not expired may be scavenged when there is memory pressure. Better to slow down because you have to reread the database and recreate the cached data than to fault completely because an allocation can not be performed. And that's the answer for the original poster as well. Stick your country list in the cache with no expiration but always access it via a method that tries the cache and if it isn't there recreates it from the database and caches it. This gives you multiple advantages: only one piece of code knows how to to create the list from the database; you don't populate the cache till you need to the first time; your application degrades gracelly if memory get's tight; unless you have memory pressure your performance is exactly the same as putting it in application state, i.e. one read from the database all other reads from memory. -- -Blake (com/bcdev/blake)