| 4/9/2006 4:18:02 PM |
The custom Core.Cache class is a great idea. (This is what I really like about the stuff you create--so darn practical. Great stuff, Paul!) But I can't see that the single Cache instance is "attached" to anything with a lifespan greater than the current page request. What is it attached to that prevents it being destroyed by the garbage collector after the current page request has finished? |
| 4/9/2006 4:24:51 PM |
I believe you're needing to read up on "static" members (called Shared in VB by the way). The easiest way to think about them is that they are basically global variables, so they are always single instance and tied to the application's lifetime. The biggest concern with static members is that you do need to add some syncronization logic, usually with lock, for any writing to them to avoid serious issues. Obviously that means they should be used sparingly, with data that is mostly stable and unchanging, but as long as you follow those rules they are potentially wonderful things. Just don't overuse them unnecessarily since they will not be garbage collected until the application ends -- thus the standard Web Cache object is often better since it allows memory to be freed, but my argument is that my Core objects should not be constantly being freed and thus the rationale behind the custom Cache.
Thanks, Paul Wilson
|
| 4/9/2006 7:15:00 PM |
Oh, I understand the purpose of static members, but I did not know that they effectively created a singleton that was tied to the application's lifetime. So that's something I've learned. Thanks, Paul. |