C# Disposing of datacontext?
Yes, they all do the same thing. The braces only add explicit scope; by default the using only applies to the next statement. Returning out of a using will still dispose (it's essentially a try/finally behind the curtain) My preference is #3, but with the braces added for clarity.
Actually, I'd say that Method 1 is neatest IMO - I know the braces are extras, but they help clarify/organize code. And having your variable declared and returned outside the using block makes for easier real-time debugging.
They all do the same and dispose the context correctly. The first and the second are exactly the same. The first and the second both translate to the following code: int ReturnValue = 0; Context dc = null; try { dc = new CrystalCommon.MainContext(); ReturnValue = (dc.
TblHelpCentreQuestions. Where(c => c. AwaitingSupportResponse == true).Count()); } finally { if(dc!
= null) dc.Dispose(); } return ReturnValue; The third one translates to this: Context dc = null; try { dc = new CrystalCommon.MainContext(); return (dc. TblHelpCentreQuestions. Where(c => c.
AwaitingSupportResponse == true).Count()); } finally { if(dc! = null) dc.Dispose(); } Because the finally block is executed when the scope of the try block is left, both codes really are equivalent.
– Tom Gullen Apr 15 at 11:43 The finally clause is executed. From the execution point of view, the second piece of code is executed like the first piece of code. – Daniel lgarth Apr 15 at 11:45 @Tom: If finally is present, it will always be executed prior to returning scope to the caller.
– Mr. Disappointment Apr 15 at 11:45.
Talljoe explains well, they are all equivalent; all I will add is a fourth example, which actually just demonstrates what Talljoe details, but with a slight modification to formatting: public static int TicketsRequiringSupportResponse() { using (var dataContext = new CrystalCommon.MainContext()) { return dataContext . TblHelpCentreQuestions. Where( question => question.
AwaitingSupportResponse == true).Count(); } } Note, we add scoping braces for the using and further remove redundant parentheses from the return statement, then simply drop a line and indent to allow a better flow for reading, as opposed to a long line (however, long is debatable. ) I've also tried to give the DataContext and lambda argument somewhat descriptive names.
The data access objects derive from a base class which has a GetDataContext() method to initiate an instance of the data context whenever it's needed. Which happily creates/uses/disposes my DataContext (created by sqlmetal. Exe) object for each and every database interaction.
After many hours of head scratching, I think I've decided that the cause of my errors is that under load the datacontext object is being created and disposed way too much, and I need to change things to share the same datacontext for the duration of the web service request. I found this article on the internet which has a DataContextFactory that seems to do exactly what I need. Cannot access a disposed object.
...whenever my datacontext is used more than once. This is because my using (...) {} code is disposing my datacontext after its first use. So, my question is... before I go through my entire data access layer and remove loads of usings, what is the correct way to do this?
I don't want to cause a memory leak by taking out the usings, but at the same time I want to share my datacontext across different data access objects. Should I just remove the usings, and manually call the dispose method just before I return from the web service request? If so then how go I make sure I capture everything bearing in mind I have several try-catch blocks that could get messy.
I cant really gove you an answer,but what I can give you is a way to a solution, that is you have to find the anglde that you relate to or peaks your interest. A good paper is one that people get drawn into because it reaches them ln some way.As for me WW11 to me, I think of the holocaust and the effect it had on the survivors, their families and those who stood by and did nothing until it was too late.