I start a Process then I want to make sure it will be closed properly. I have used Process.Close() to close it but sometime it was still locking the resources. I can see we have Process.Dispose() method. I just want to know what are the actual differences between them and should I call them both to make sure that process will be closed?
p.Dispose();
p.Close();
From documentation of Process.Close();
The Dispose method calls Close. Placing the Process object in a using
block disposes of resources without the need to call Close.
That means, there is no difference. Internally, all Close methods in .NET calls Dispose method as far as I know.
If you look at reference source;
public void Close()
{
...
m_processHandle.Close();
...
}
and this method calls;
public void Close() {
Dispose(true);
}
You should always use using statement for a Process object. It allows early cleanup of resources so you don't need to wait until they garbage collected.
Difference between Close() and Dispose() Method
Close() Vs Dispose() Method
The basic difference between Close() and Dispose() is, when a Close() method is called, any managed resource can be temporarily closed and can be opened once again. It means that with the same object the resource can be reopened or used. Whereas Dispose() method permanently removes any ((un)managed) resource from memory for cleanup and the resource no longer exists for any further processing.
Example showing difference between Close() and Dispose() Methods:
using System;
using System.Data;
using System.Data.SqlClient;
public class Test
{
private string connString = "Data Source=COMP3;Initial Catalog=Northwind;User Id=sa;Password=pass";
private SqlConnection connection;
public Test()
{
connection = new SqlConnection(connString);
}
private static void Main()
{
Test t = new Test();
t.ConnectionStatus();
Console.ReadLine();
}
public void ConnectionStatus()
{
try
{
if(connection.State == ConnectionState.Closed)
{
connection.Open();
Console.WriteLine("Connection opened..");
}
if(connection.State == ConnectionState.Open)
{
connection.Close();
Console.WriteLine("Connection closed..");
}
// connection.Dispose();
if(connection.State == ConnectionState.Closed)
{
connection.Open();
Console.WriteLine("Connection again opened..");
}
}
catch(SqlException ex)
{
Console.WriteLine(ex.Message+"\n"+ex.StackTrace);
}
catch(Exception ey)
{
Console.WriteLine(ey.Message+"\n"+ey.StackTrace);
}
finally
{
Console.WriteLine("Connection closed and disposed..");
connection.Dispose();
}
}
}
In the above example if you uncomment the connection.Dispose() method and execute, you will get an exception such as
The ConnectionString property has not been initialized.
This is the difference between Close() and Dispose().
Dispose normally free's the UnManaged resources that are held inside the class. It has no effect on the process itself.
so far to dispose. As taken from the MSDN the Close mehtod does:
Frees all the resources that are associated with this component.
ref: MSDN Process.Close()
So from the outside there is no difference, but lets take a look in the glorious .net SourceCode: Process
/// <devdoc>
/// <para>
/// Frees any resources associated with this component.
/// </para>
/// </devdoc>
public void Close() {
if (Associated) {
if (haveProcessHandle) {
StopWatchingForExit();
Debug.WriteLineIf(processTracing.TraceVerbose, "Process - CloseHandle(process) in Close()");
m_processHandle.Close();
m_processHandle = null;
haveProcessHandle = false;
}
haveProcessId = false;
isRemoteMachine = false;
machineName = ".";
raisedOnExited = false;
//Don't call close on the Readers and writers
//since they might be referenced by somebody else while the
//process is still alive but this method called.
standardOutput = null;
standardInput = null;
standardError = null;
output = null;
error = null;
Refresh();
}
}
while dispose does this
/// <internalonly/>
/// <devdoc>
/// <para>
/// Free any resources associated with this component.
/// </para>
/// </devdoc>
protected override void Dispose(bool disposing) {
if( !disposed) {
if (disposing) {
//Dispose managed and unmanaged resources
Close();
}
this.disposed = true;
base.Dispose(disposing);
}
}
So as you can see, even internally there is no difference. Dispose just wraps the close mehtod.
This is one of those cases where MSDN is actually really helpful
https://msdn.microsoft.com/en-us/library/fs2xkftw(v=vs.110).aspx
notice that if you want to use the "using" construction:
using (MyResource myRes = new MyResource())
{
myRes.DoSomething();
}
you need your object to support IDisposable, and:
The IDisposable interface requires the implementation of a single
parameterless method, Dispose.
the Dispose method is also what is called by the garbage colledtor, before removing all references to the object, ensuring that the object is nicely cleaned up..
Hence the implementation of IDisposable, and usage of such, is a way for you to ensure that the resources hugged by an object are freed, before the object is actually removed from memory by garbage collector..
you can enforce this by using using
genericly close does not implement this.
but sometimes it does wrap the Dispose method:
https://msdn.microsoft.com/en-us/library/system.io.stream.close(v=vs.110).aspx
Closes the current stream and releases any resources (such as sockets and file handles) associated with the current stream. Instead of calling this method, ensure that the stream is properly disposed.
for the Process class, it's the other way around.
Related
Do I need to call dispose in the finally block for SqlTransaction? Pretend the developer didnt use USING anywhere, and just try/catch.
SqlTransaction sqlTrans = con.BeginTransaction();
try
{
//Do Work
sqlTrans.Commit()
}
catch (Exception ex)
{
sqlTrans.Rollback();
}
finally
{
sqlTrans.Dispose();
con.Dispose();
}
Do I need to use try-finally or the using-statement to dispose the SqlTransaction?
It does not hurt to have it. This is true for every class implementing IDisposable, otherwise it would not implement this interface.
But normally the garbage collector deals with unreferenced objects(it doesn't mean that the GC calls dispose, which isn't true), so you need it only for unmanaged resources. But because i also don't want to call dispose on every other variable or use the using-statement everywhere, it it's always worth to look into the actual implementation of the class' Dispose method.
SqlTransaction.Dispose:
protected override void Dispose(bool disposing)
{
if (disposing)
{
SNIHandle target = null;
RuntimeHelpers.PrepareConstrainedRegions();
try
{
target = SqlInternalConnection.GetBestEffortCleanupTarget(this._connection);
if (!this.IsZombied && !this.IsYukonPartialZombie)
{
this._internalTransaction.Dispose();
}
}
catch (OutOfMemoryException e)
{
this._connection.Abort(e);
throw;
}
catch (StackOverflowException e2)
{
this._connection.Abort(e2);
throw;
}
catch (ThreadAbortException e3)
{
this._connection.Abort(e3);
SqlInternalConnection.BestEffortCleanup(target);
throw;
}
}
base.Dispose(disposing);
}
Without understanding all(or anything) what is happening here i can say that this is more than a simple base.Dispose(disposing). So it might be a good idea to ensure that a SqlTransaction gets disposed.
But because SqlConnection.BeginTransaction creates the transaction it could also be a good idea to reflect this also:
public SqlTransaction BeginTransaction(IsolationLevel iso, string transactionName)
{
SqlStatistics statistics = null;
string a = ADP.IsEmpty(transactionName) ? "None" : transactionName;
IntPtr intPtr;
Bid.ScopeEnter(out intPtr, "<sc.SqlConnection.BeginTransaction|API> %d#, iso=%d{ds.IsolationLevel}, transactionName='%ls'\n", this.ObjectID, (int)iso, a);
SqlTransaction result;
try
{
statistics = SqlStatistics.StartTimer(this.Statistics);
SqlTransaction sqlTransaction = this.GetOpenConnection().BeginSqlTransaction(iso, transactionName);
GC.KeepAlive(this);
result = sqlTransaction;
}
finally
{
Bid.ScopeLeave(ref intPtr);
SqlStatistics.StopTimer(statistics);
}
return result;
}
As you can see. The GC will also keep the Connection alive when a Transaction is created. It also doesn't hold a reference to the transaction since it only returns it. Hence it might not be disposed even when the connection is already disposed. Another argument to dispose the transaction.
You might also have a look at the TransactionScope class which is more fail-safe than BeginTransaction. Have a look at this question for more informations.
In the general case, every IDisposable object you construct or obtain, and own, you have to dispose of.
In the specific case, there are some exceptions, but SqlTransaction is not one of them.
As per the the documentation of SqlTransaction.Dispose:
Releases the unmanaged resources used by the DbTransaction and optionally releases the managed resources.
(my emphasis)
Since the documentation does not state that those unmanaged resources are released when you issue a commit or a rollback, you will need to dispose of this object.
I think you can just close connection. I checked the code of BCL -- seems like connections takes care of its transaction -- no need to close it explicitly.
public CategorieEquipement Select(int NoType)
{
SqlConnection cx = new SqlConnection(WebConfigurationManager.ConnectionStrings["SQLConnect"].Connection String);
SqlDataReader reader;
CategorieEquipement lstCategorie = new CategorieEquipement();
try
{
cx.Open();
SqlCommand com = new SqlCommand("SELECT_CategorieEquip", cx);
com.CommandType = System.Data.CommandType.StoredProcedure;
com.Parameters.AddWithValue("#where",NoType);
reader = com.ExecuteReader();
while (reader.Read())
{
lstCategorie.CodeRef = reader["CodeRef"].ToString();
}
}
catch (Exception ex)
{
Debug.WriteLine("SELECT ERROR : " + ex.ToString());
return null;
}
finally
{
if (cx != null)
{
cx.Close();
}
}
return lstCategorie;
}
}
My question is if I remove the finally block of code, will the garbage collector close the connection when disposing of the SQlConnection object?
I know it is a better practice to be explicit but my coworker doesn't agree .
will the garbage collector close the connection when disposing of the
SQlConnection object?
Garbage collector is not responsible for calling Dispose on an object, usually Dispose is called in the Finalizer, only then GC would be able to properly dispose the object.
One important thing to note is that you cannot predict when the garbage collection process will run, so it is always better to explicitly dispose objects (which implements IDisposable).
As far as database connections are concerned the approach should be open as late as possible and close as early as possible.
In the case above cx.Close(); should be enough, instead, you can also call cx.Dispose, But a better approach would be to enclose the SqlConnection in using statement block.
That will translate into try/finally block and it will ensure the SqlConnection disposal.
The garbage collection will dispose it, but since it is non-deterministic you don't know when it will do it.
C# provide the using structure to dispose unmanaged code and it is recommended to use it:
using (SqlConnection cx = new SqlConnection(WebConfigurationManager.ConnectionStrings["SQLConnect"].ConnectionString);)
{
}
Tell your co-workers they ought to wrap any instance of objects that implement the IDisposable interface in a using so that they will be disposed in a deterministic fashion to ensure a correct management of the application resources and avoid problems like memory leaks.
private void BeginListen()
{
while (isWatch)
{
try
{
Socket newSocket = socket.Accept();
ConnectionClient conn = new ConnectionClient(newSocket, ShowMsg, RemoveClientConnection, SendMsgToController);
string strRemoteEndPoint = newSocket.RemoteEndPoint.ToString();
if (dictConn.ContainsKey(strRemoteEndPoint.Substring(0, strRemoteEndPoint.LastIndexOf(":"))))
dictConn[strRemoteEndPoint.Substring(0, strRemoteEndPoint.LastIndexOf(":"))].isRec = true;
else
dictConn.Add(strRemoteEndPoint.Substring(0, strRemoteEndPoint.LastIndexOf(":")), conn);
UpdateControllerStatus(strRemoteEndPoint, " online");
}
catch (Exception ex)
{
ExceptionLog(ex);
}
}
}
This method is used for listening.
If I use thread to create this method
myThread = new Thread(new ThreadStart(BeginListen));
myThread.IsBackground = true;
myThread.Start();
Will it be collected by GC when catching an exception?
Or do I need to add GC.Collect(); manually in the catch?
What do you want to be collected? Well, generally you shouldn't call GC.Collect yourself.
I would leave it for the GC to collect the objects and reclaim memory resources. But when something implements IDisposable, you generally should use the using statement.
In the example provided, maybe you don't need to use a using statement, because the socket may be used later, also, maybe there is already some code to dispose the object inside your ConnectionClient class. Disposing it now could cause you problems.
But generally you can use the using statement to automatically handle the disposal of resources, eg opening file streams, creating memory streams, and so on.
To learn more about what the using statement does, Click here.
I was searching the web for a while now. But didn't find any clear answer to my question. Whether when connecting to a database I should use "using" or I can just go with try-catch-finally? What I mean is:
I don't know if I should call the dispose method each time I finish interacting with the database or just close the connection.
static public List<Category> GetAll()
{
List<Category> CategoryList;
try
{
BaseDAO.Dbconn.Open();
BaseDAO.SetCommand(BaseDAO.CommandAction.Read, "SELECT * FROM Categories");
CategoryList = new List<Category>();
using (DbDataReader reader = BaseDAO.Dbcmd.ExecuteReader())
{
while (reader.Read())
{
int ID = reader.GetInt32(reader.GetOrdinal("CategoryID"));
string Name = reader.GetString(reader.GetOrdinal("CategoryName"));
string Description = reader.GetString(reader.GetOrdinal("Description"));
CategoryList.Add(new Category(ID, Name, Description));
}
}
return CategoryList;
}
catch (Exception ex)
{
BaseDAO.Dbconn.Dispose();
throw ex;
}
finally { BaseDAO.Dbconn.Close(); }
}
The "Dbconnection" is static not sure if this is a good solution as well...
I am getting to know ADO and just wanted to know what's the best answer for this kind of question.
It doesn't make any difference - whatever you prefer. The using clause gets turned into a try-finally by the compiler anyway.
EDIT I just noticed you are only calling Dispose if an exception occurs. You should move this into the finally clause as well. Dispose will call Close, so you don't need to specifically call it if you don't want to.
Further edit Given that, as you say, your DbConnection is static, then you don't want to call Dispose, but you do need to call Close. However, there should not be any need to use a static DbConnection - connection pooling will take care of efficiently handling the connections. Your code should create a new connection instance every time.
Reference: Using Statement C#.
The using statement allows the programmer to specify when objects that use resources should release them.
The object provided to the using statement must implement the
IDisposable interface. This interface provides the Dispose method,
which should release the object's resources.
A using statement can be exited either when the end of the using statement is reached or if an exception is thrown and control leaves the statement block before the end of the statement.
Reference : Example
As per Code Project, the .NET CLR converts
using (MyResource myRes = new MyResource())
{
myRes.DoSomething();
}
to:
{
// limits scope of myRes
MyResource myRes= new MyResource();
try
{
myRes.DoSomething();
}
finally
{
// Check for a null resource.
if (myRes!= null)
// Call the object's Dispose method.
((IDisposable)myRes).Dispose();
}
}
Calling Dispose is equivalent to calling Close in most (if not all) DbConnection implementations, so there's no need to call the former if you are already calling the latter. Just make sure you do so in a finally in case there's an exception.
try
{
using (MapDataContainer ent = new MapDataContainer()) //is an autogen'd EF object
{
//do some stuff, assume it throws an error
}
}
catch(Exception ex) //catching outside using not sure if IDispose called
{
//handle error
}
Normally I understand that the using called the IDispose on the EF object. So supposing it threw an exception... Is this a possible memory leak scenario?
You're fine. "using" is actually a try..finally in disguise.
The using statement is actually
ResourceType resource = expression;
try {
statement;
}
finally {
if (resource != null) ((IDisposable)resource).Dispose();
}
So as you can see, the Dispose is always called. The only exception is if it is a CLR error, but in that case you're out of luck anyway.
As MSDN says, using statement is translated by C# compiler to try-finally block to ensure, that IDisposable.Dispose() is called:
{
MapDataContainer ent = new MapDataContainer();
try
{
...
}
finally
{
if (ent != null)
((IDisposable)ent).Dispose();
}
}
The only cases when IDisposable.Dispose() is not called is when Environment.FailFast is called inside using statement block or when exception is thrown inside or right after the constructor of MapDataContainer(), but this still doesn't prevent Garbage collector to collect this object. Additionally objects that implements IDisposable typically (but not necessarily) call IDisposable.Dispose() in destructor to ensure that any unmanaged resources will be correctly released even in programmer forgets to call it manually or wrap it in using statement.