Dapper source code - will this dispose of my connection properly? - dapper

Looking at the source code for Dappers QueryAsync method
SqlMapper.Async.cs
private static async Task<IEnumerable<T>> QueryAsync<T>(this IDbConnection cnn, Type effectiveType, CommandDefinition command)
{
using (var cmd = command.TrySetupAsyncCommand(cnn, info.ParamReader))
{
DbDataReader reader = null;
try
{
if (wasClosed) await cnn.TryOpenAsync(cancel).ConfigureAwait(false);
var func = tuple.Func;
if (command.Buffered)
{
var buffer = new List<T>();
var convertToType = Nullable.GetUnderlyingType(effectiveType) ?? effectiveType;
while (await reader.ReadAsync(cancel).ConfigureAwait(false))
{
object val = func(reader);
if (val == null || val is T)
{
buffer.Add((T)val);
}
else
{
buffer.Add((T)Convert.ChangeType(val, convertToType, CultureInfo.InvariantCulture));
}
}
while (await reader.NextResultAsync(cancel).ConfigureAwait(false)) { /* ignore subsequent result sets */ }
command.OnCompleted();
return buffer;
}
else
{
// can't use ReadAsync / cancellation; but this will have to do
wasClosed = false; // don't close if handing back an open reader; rely on the command-behavior
var deferred = ExecuteReaderSync<T>(reader, func, command.Parameters);
reader = null; // to prevent it being disposed before the caller gets to see it
return deferred;
}
}
finally
{
using (reader) { /* dispose if non-null */ }
if (wasClosed) cnn.Close();
}
}
}
Note this line (413):
using (var cmd = command.TrySetupAsyncCommand(cnn, info.ParamReader))
My question is, will my connection be disposed of correctly without me having to wrap my code calling in to this in a using block?

Note following line in the code you post:
private static async Task<IEnumerable<T>> QueryAsync<T>(this IDbConnection cnn,....
That shows QueryAsync is an extension method of IDbConnection. That means, instance of connection is created in your code somewhere.
As mentioned here, there are two ways to manage connection with Dapper:
Fully manage yourself:
Here, you are fully responsible for opening and closing connection. This is just like how you treat connection while working with ADO.NET.
Allow Dapper to manage it:
Dapper automatically opens the connection (if it was not opened) and closes it (if it was opened by Dapper) for you.
Considering this, only choice remain here is to open/close connection in your code or allow Dapper to do this for you. If you are doing this yourself then Dapper does not interfere at all.
If you want to allow Dapper to handle the open/close connection for you and are worried that whether it will close it properly, then yes, it closes it properly.
Find following code in your post:
if (wasClosed) await cnn.TryOpenAsync(cancel).ConfigureAwait(false);
....
if (wasClosed) cnn.Close();
Dapper maintains the state/flag in wasClosed variable if connection was opened by Dapper. You can see in your code that the connection is also properly closed at the end. Further, you can further check the Dapper source code to see how the this is handled in multiple methods. Specially check SqlMapper.Async.cs and SqlMapper.cs files.
Now, this is all about open/close. What about Dispose? Following is what Marc Gravell says in one of the comment for this answer: https://stackoverflow.com/a/12629170/5779732
well, technically open/closed is different to disposed. If you are only going to be opening/closing around the individual calls, you might as well let dapper do it. If you are opening/closing at a wider granularity (per request, for example), it would be better for your code to do it and pass an open connection to dapper.
So, if you really want to Dispose the connection instead of just open/close, better you wrap it in using block in your code and pass open connection to Dapper. As mentioned in the comment, this post discusses difference between Dispose and Close.

Related

How does Dapper execute query without explicitly opening connection?

We are using Dapper for some data access activity and are using the standard recommended approach for connecting to database as follows:
public static Func<DbConnection> ConnectionFactory = () => new SqlConnection(ConnectionString);
However, if we try and execute a statement, in the docs it show that you need to first state:
using (var conn = ConnectionFactory())
{
conn.Open();
var result = await conn.ExecuteAsync(sql, p, commandType: CommandType.StoredProcedure);
return result;
}
That means, you have to explicitly open the connection. However, if we leave out the statement conn.open(), it also works and we are worried if in such cases the connection may not be disposed of properly.
I would appreciate any comments as to how the SQL gets executed without explicitly opening any connection.
Dapper provide two ways to handle connection.
First is - Allow Dapper to handle it.
Here, you do not need to open the connection before sending it to Dapper. If input connection is not in Open state, Dapper will open it - Dapper will do the actions - Dapper will close the connection.
This will just close the connection. Open/Close is different than Dispose. So, if you really want to Dispose the connection better switch to second way.
Second is - Handle all yourself.
Here, you should explicitly create, open, close and dispose the connection yourself.
Please refer to following links for more details:
https://stackoverflow.com/a/51138718/5779732
https://stackoverflow.com/a/41054369/5779732
https://stackoverflow.com/a/40827671/5779732

Database connection is not closing properly

I am using C# linq to sql application and my application is running 24*7 in servers. Now i am facing the issue database connections they are not closing so active connects reach to 200 and more. I used using syntax everywhere I am dealing the database directly.
But this is not solving my problem. Please check and let me know what best i can do for this.
Provider always disabled my database.
using (DataClassesDataContext DbContext = new DataClassesDataContext())
{
return DbContext.tblApiLinks.FirstOrDefault(U => U.ProviderName == ProviderName);
}
using (DataClassesDataContext DbContext = new DataClassesDataContext())
{
tblApiLink Apilink = new tblApiLink();
Apilink.ApiUrl = Url;
Apilink.ApiKey = Key;
Apilink.ProviderName = Provider;
DbContext.tblApiLinks.InsertOnSubmit(Apilink);
DbContext.SubmitChanges();
}
New Edits
Case 1. Please check these code it returning a table. Does this effect to close the connection?
public tblApiLink getData()
{
using (DataClassesDataContext DbContext = new DataClassesDataContext())
{
return DbContext.tblApiLinks.FirstOrDefault(U => U.ProviderName == ProviderName);
}
}
tblApiLink api = getData();
Case 2. If I used like this tblApiLinks lst= dbContext.tblApiLinks;
I think this will not close the connection and they will be active all time.
Case 3. Is there any way to close all sleeping connection which is active from long time and not in use.
In your "case 1" try to set a variable that stores what you want to return, and return the value after the using block is closed.
Example:
tblApiLink returnData = null;
using(DataClassesDataContext DbContext = new DataClassesDataContext())
{
returnData = DbContext.tblApiLinks.FirstOrDefault(U => U.ProviderName == ProviderName);
}
return returnData;
Side note: The type tblApiLink isn't correctly named according to convention, I suggest you refactor it if possible.
Case 2: I don't understand what you mean.
Case 3: You could use a singleton that handles connections and closes them, but the proper way to do this is disposing the connections that are no longer active. If you really want to kill active connections your best bet would be on the server, either manually or storing a procedure that you can call later on.

Does the SQL connection not get closed if you put the datareader in a using block?

So, I recently inherited a large project that uses the following data access pattern; unfortunately, this is resulting in a massive number of timeout exceptions related to connection pooling.
Timeout expired. The timeout period elapsed prior to obtaining a
connection from the pool. This may have occurred because all pooled
connections were in use and max pool size was reached"
It clear that the connections are leaking and not getting closed properly.
So, the framework has a DataAccess class with the method GetDataReader.
When the data reader is referenced, it is placed inside a using block, but connections are still leaking.
Does the fact that the connection is not explicitly closed or placed in a using block the reason why the connections are getting leaked?
Normally, I would wrap the connection in a using block AND wrap the data reader in a using block.
Obviously, this framework is very flawed, but would somehow using the option CommandBehavior.CloseConnection for the data reader resolve this issue?
None the external code accesses the SqlConnection directly and has to go through this DataAccess class.
public IDataReader GetDataReader(QueryDto dto)
{
DateTime current = DateTime.Now;
Database db = DatabaseFactory.CreateDatabase(dto.DatabaseName);
DbCommand cmd = db.GetStoredProcCommand(dto.StoredProcedureName);
if (dto.Params.Length > 0)
{
cmd = db.GetStoredProcCommand(dto.StoredProcedureName, dto.Params);
}
dto.Command = cmd;
cmd.CommandTimeout = dto.Timeout;
cmd.Connection = db.CreateConnection();
try
{
cmd.Connection.Open();
}
catch (SqlException ex)
{
// Handle Exception here...
throw;
}
return rdr;
}
Usage in some static repository class:
var query = new QueryDto
{
DatabaseName = "SomeDatabase",
Params = parms,
StoredProcedureName = "StoredProcedureName"
};
using (IDataReader dr = dataAccess.GetDataReader(query))
{
while (dr.Read())
{
// do stuff here
}
}
I think your problem is that the using statement is around a function that has open resources embedded in it. The using will not dispose of the connection that is opened inside GetDataReader. I think your are correct that the Connection itself needs to be in a using block. The using statement only calls Dispose on the object that is passed in, not any nested resources.

WP7 HttpWebRequest check if file exists (synchronously)

I need to check if a file exists and I need to do it from several places in code.
Some of the places I can handle it with a callback (kinda ugly but it will work). But the one I don't know how to handle seems to require that it be Synchronous.
I need to call the method to check if it exist from a RelayCommand as the "canExecute" method.
Any ideas on how to handle this?
This is what I currently have but calling the .WaitOne on the UI thread is blocking the background worker so it completely locks the app.
private bool FileExists(Uri file)
{
var exists = false;
ManualResetEvent resetEvent = new ManualResetEvent(false);
BackgroundWorker worker = new BackgroundWorker();
worker.DoWork += (s, e) =>{
WebRequest request = HttpWebRequest.Create(file);
request.Method = "HEAD"; //only request the head so its quick
request.BeginGetResponse(result =>
{
try
{
//var response = request.EndGetResponse(result);
var req = (HttpWebRequest)result.AsyncState;
HttpWebResponse response = (HttpWebResponse)request.EndGetResponse(result);
exists = (response.StatusCode.ToString() == "OK");
}
catch
{
exists = false;
}
resetEvent.Set();
}
, request);
};
worker.RunWorkerAsync();
resetEvent.WaitOne();
return exists;
}
You should never make HTTPWebRequest's synchronous on the UI thread - this could block the UI for seconds or minutes...
If you really want to make an HTTPWebRequest appear to be synchronous on a background thread then simply use a ManualResetEvent inside a callback - e.g. something like:
var resetEvent = new ManualResetEvent();
theHttpWebRequest.BeginGetResponse((result) => {
var response = theHttpWebRequest.EndGetResponse(result);
// use response.StatusCode to check for 404?
resetEvent.Set();
});
resetEvent.WaitOne();
Also, please note that checking if a file exists over HTTP might be better done by calling a small webservice which does the check - it depends on the size of the file you are checking.
AFAIK this is not possible. You can never make synchronous calls to web services in Silverlight.
You have to leave canExecute method empty (to always execute the command), and make async call to check if file exists in handler for the command. The real code for the command has to execute in handler for that async call.
I think it is only way you can manage it.
btw-you can use lambda expressions to make it look more like synchronous code. Or maybe Reactive Extensions may help with better looking code (jesse's tutorial).
The way I would approach this problem is to create some kind of flag ( i.e IsFileExists) and return that flag from CanExecute method. Flag shold be set to false initially and your button disabled under assumption that untill we know that file does exits we consider it doesn't. Next I would fire HTTPWebRequest or wcf call or any other async method to check if file exists. Once callback confirms that file exists set flag to true and fire CanExecuteChanged event. If you want to be fancy you can add some visual feedback while waiting for responce. In general user experienc would be much better than locking up screen for duration of the web request.

SubSonic - Need to manually force connections closed?

In using Enterprise Library, there was an issue with having to manually close db connections, as GC, when scanning the heap, looks for items out of scope.
A connection that is part of a pool that is being used but the connection state is broken or fetching, but you have already received your results, will be kept open, and connection handles in the pool will run out.
Thus, adding manual connection checking and forcedly closing the connections is good form.
Now, take SubSonic. With an EntLib base, I am doing the following in a finally block:
public static bool GetISOCountryCodes(out DataSet dsISOCountryCodes, out Response dbResponse)
{
dbResponse = new Response();
dsISOCountryCodes = new DataSet();
StoredProcedure sp = null;
try
{
sp = SPs.GetISOCountryCodes(null);
dsISOCountryCodes = sp.GetDataSet();
// set the response object properties
dbResponse = new Response((int)sp.OutputValues[0]);
return dbResponse.IsValid;
}
catch (System.Exception ex)
{
return dbResponse.IsValid;
}
finally
{
if (sp.Command != null && sp.Command.ToDbCommand().Connection != null &&
sp.Command.ToDbCommand().Connection.State == ConnectionState.Open)
sp.Command.ToDbCommand().Connection.Close();
}
}
I know it's been said that you don't have to manually do this, as SubSonic will do this for you, however, I'd like to know if anyone has run into issues with SubSonic not closing connections (once again, as it uses EntLib at the root), and if there are better ways of accomplishing this.
Obviously, in all my data caller methods, I will reference one, say, "ConnectionCloser()" method.
Thanks.
This post was more of a notification for discussion. However, I'm not sure if the issue has actually been resolved with v5. So essentially the answer is to continue checking in the finally block.

Resources