Memory consequences of caching context.
We have basically a console type app that could be up for a long time. For performance reasons we are making the CatalogContext, OrderContext, OrderManagementContext, ProfileContext, etc. static members of a class, only initializing and building them once for the application lifetime (with the requisited sychronization locking). My question, is there memory implications to holding on to these context handles? Are references to queries, results, etc. held by the context handles effectively causing a "memory leak" with .NET since the reference is always held? Any input, ideas, or experience that can be shared? If there are is it a problem with all of the context or a specific one? What would be the suggestion to efficiently remove these references (if they exist) and still have the context usable for the next call?
Thank you.
Kevin
Answers
- You should use GetOrdersAsXML. Xml object are ligther than datasets.
- Marked As Answer byKevinBurton Monday, November 02, 2009 7:37 PM
- Proposed As Answer byCyril Rebreyend Friday, October 30, 2009 4:36 PM
All Replies
There should be no problem at all with you holding on to a single instance of these objects for the lifetime of your application. They were designed with the intent that a single instance will exist for a process's lifetime. You would actually see more problems if you tried to frequently create and destroy the context objects, as these operations can be quite expensive (especially for the ProfileContext objects).
- David
- Unmarked As Answer byKevinBurton Friday, October 30, 2009 3:12 PM
- I still think I have a memory leak. Over the space of 24 hours under load my application grows to over 2Gb. I have tried many different tools to try and track down if I indeed have a memory leak. I consistently get a "memory corrupted" exception when the application grows this big and it always occurs in the GetOrderAsDataSet call. I have unchecked the debug flag concerning JIT with no effect. Any ideas on either CS fixes or general memory leak debugging. The problem with tools like windbg in trying to detect memory leaks is that there is so much data and it is hard to find the "name" of the root object.
Kevin - You should use GetOrdersAsXML. Xml object are ligther than datasets.
- Marked As Answer byKevinBurton Monday, November 02, 2009 7:37 PM
- Proposed As Answer byCyril Rebreyend Friday, October 30, 2009 4:36 PM
- How did you create the different context?
http://gaelduhamel.spaces.live.com; http://www.twitter.com/GaelDuhamel; http://www.itcreme.com - I am not sure if I follow the question. I create a context like:
OrderSiteAgent siteAgent = new OrderSiteAgent(this.OrderManagementContextInitString); return OrderManagementContext.Create(siteAgent);
Then instead of calling Create with each invocation I just return the already created context (using the cached value).
Kevin

