I would like to know if there are any pitfalls on calling a static method from an ASP.NET web service.
internal static object SelectScalar(String commandText, DataBaseEnum dataBase)
{
SqlConnection sqlc = new SqlConnection(AuthDbConnection.GetDatabaseConnectionString());
object returnval=null;
if (sqlc!=null)
{
SqlCommand sqlcmd = sqlc.CreateCommand();
sqlcmd.CommandText = commandText;
sqlc.Open();
returnval = sqlcmd.ExecuteScalar();
}
return returnval;
}
So for an example the method above; are there any pitfalls on multiple web methods and multiple clients calling this method at the same time (say, 1000 calls to a web method that calls this function)?
Since you're creating a new SqlConnection, you want to dispose it or the connection won't close. See MSDN for usage guidelines.
The fact that its a static method though... that doesn't seem to be an issue since you're not updating any shared state (global variables).
EDIT: AFAIK, the 'pitfalls' of static methods in webservices are the same as in any other application. The only thing to keep a note of is that a webservice is a server that is expected to run reliably for a long period of time. Thus things that could cause problems over time (memory leaks, db connection exhaustion, etc) are more significant than for other applications that run for a much shorter time period.
I don't know if C# is like Java, but opening a SQL connection and failing to close it before leaving the method doesn't seem like a good idea for me. The GC will clean it up once it goes out of scope, but that's not the same thing as closing the connection in Java.
The idiom in Java would demand that you close the connection in a finally block. Unless you're certain that the C# class doesn't require such a thing, I'd look into it.
You'll find out soon enough - thousands of web calls will exhaust the number of connections available quickly if they're scarce.
One more thing to check: opening connections this way is expensive in Java, so they're usually pooled. Is connection pooling also done in C#? Is it inefficient to keep opening and closing a database connection? Could you accomplish the same thing with a static, shared connection? If you go that way, perhaps threading issues come into play.
The thing to be aware about is when static members change state that is accessible to other threads in the application domain. In these cases, you have to take the proper measures to make it happen in an orderly way.
Your method does not touch any state out of itself (everything is local) so you're OK.
As duffymo and nader noted, you should dispose of your connection as you should dipose of any object that implements IDisposable.
Related
I have seen examples where someone is doing:
IDbConnection db = new MySqlConnection(conn);
var people = db.Query<People>("SELECT * FROM PEOPLE").ToList();
or is the above a bad practice and should all queries be put in using statements like so:
using (var db = new MySqlConnection(conn))
{
var people = db.Query<People>("SELECT * FROM PEOPLE").ToList();
}
As others have correctly noted, the best practice in general is to use using any time an object implements IDisposable and you know that the lifetime of the object is going to be short -- that is, not longer than the duration of the current method. Doing so ensures that scarce operating system resources are cleaned up in a timely manner. Even if an object's disposal is "backstopped" by its finalizer, you don't want to be in a situation where, say, you have a lock on a file or database or something that is not going to be released until the finalizer runs several billion nanoseconds from now.
However I would temper that advice by saying that there are a small number of types that implement IDisposable for reasons other than timely disposal of unmanaged resources. In some very specific cases you can safely skip the using. However, it is almost never wrong to use using, even when it is not strictly speaking necessary, so my advice to you is to err on the side of caution and over-use, rather than under-use using.
Dapper doesn't have a view on this; what you are using here is the database connection. If you have finished with the connection: you have finished with the connection. Basically, yes, you should probably be using using.
The main purpose use of using statments is to release unmanaged resources.When an object is no longer used The garbage collector automatically releases the memory allocated to it but sometimes the garbage collector does not release resources such as files, streams or db connection like in your example.
Think of it of a way to explicitly dispose objects rather than leave it up to the compiler so you can say it's better practice.
In my experience with Sql Server and Oracle (using the ODP.Net drivers and the MS drivers), you need to use using around Connections, Commands and Transactions or you will soon exhaust your connection pool if you do anything but the simplest database interaction in a production environment (the connection pool is typically ~50 - 200 connections).
You may not notice the behaviour in a development environment because debug = a lot of restarts, which clears the pool.
As Eric Lippert above said, it is good practice in general to use using around IDisposable objects.
In practice, you can skip "using" on Parameters for SqlServer and Oracle.
My DBA says that there are way too many connection open and he thinks it is my code in .net that is leaving them open.
I am using LINQ querys and EF code first.
Example Method:
public List<Stuff> GetStuff()
{
var db = new DBContext();
var results = db.stuff.toList();
return results;
}
Do I need to dispose the db var once I am done? My understanding is that I didn't need to in EF and LINQ. Please point me to a Microsoft documentation about managing connection in code or best practices for LINQ/EF and db connections
Update:
I added
db.Connection.Close();
db.Dispose();
and I still see the open connection in SQL after the two lines were executed. Is there a reason why it wouldn't close when I force it to close?
You should listen to your DBA! Yes, use a using. Do not leave connections open unnecessarily. You should connect, do your business with the db, and close that connection, freeing it up for another process. This is especially true in high volume systems.
Edit. Let me further explain with my own experiences here. In low volume processing, it probably isn't an issue, but it's a bad habit not to dispose of something explicitly or not-wrap it in a using when it clearly implements IDisposable.
In high-volume situations, this is just asking for disaster. Sql server will allot so many connections per application (can be specified in the connection string). What happens is processes will spend time waiting for connections to free up if they're not promptly closed. This generally leads to timeouts or deadlocks in some situations.
Sure, you can tweak Sql server connection mgmt and such, but everytime you tweak a setting, you're making a compromise. You must consider backups running, other jobs running, etc. This is why a wise developer will listen to their DBA's warnings. It's not always all about the code...
I just asked this same question over on Programmers.SE. Robert Harvey gave a great answer.
In general, you don't need to use Using statements with Entity Framework data contexts. Lazy collections is one of the reasons why.
I encourage you to read the entire answer on Programmers.SE as well as the links Robert provides in the answer.
The entity framework uses, as far as i know, connection pooling by default to reduce the overhead of creating new connections everytime.
Are the connections closed when you close your application?
If so, you could try to decrease the Max Pool Size in your connection string or disable connection pooling entirely.
See here for a reference of possible options in your connection string.
By default DbContext automatically manages the connection for you. So you shouldn't have to explicitly call Dispose.
Blog post on the subject: Link
But I believe not disposing can cause performance issues if you're processing a lot of requests. You should add a using statement to see whether or not it's causing a problem in your case.
Yes, if your method defines a Unit of Work; no, if something more primitive. (P.S. something somewhere in your code should define a Unit of Work, and that thing should be wrapped in a using (var context = new DbContext()) {} or equivalent.)
And if you belong to the school of thought that your DbContext is your Unit of Work, then you'll always be wrapping that bad boy with a using block: the local caching of data previously fetched during the context lifetime together with the SaveChanges method act as a sort of lightweight transaction, and your Dispose (without calling SaveChanges) is your Rollback (whereas your SaveChanges is your Commit).
Check this out, here's a standard protocol on how to use IDisposable objects.
https://msdn.microsoft.com/en-us/library/yh598w02.aspx
It says:
"As a rule, when you use an IDisposable object, you should declare and instantiate it in a using statement."
As they have access to unmanaged resources, you should always consider a "using" statement.
So I am finding myself struggling which is the best practice. This is my first time coding C# and first time coding anything in like a decade. Back when I worked as a php / sql programmer, we usually frowned on the idea of opening a new connection for every query, but the more I research this question on google today, specifically with C# and sqlite, the more it seems many recommend doing the polar opposite.
So, I was hoping the put this question out for some of you guys, who have obviously been doing this a lot more than eye. Here is the general setup of my database class:
class DatabaseController
{
static private SQLiteConnection _sqlconn;
static private string _uri;
public static SQLiteConnection Sqlconn
{
get { return DatabaseController._sqlconn; }
set { DatabaseController._sqlconn = value; }
}
public static string Uri
{
get { return DatabaseController._uri; }
set { DatabaseController._uri = value; }
}
}
The second class, which is the main Database class, which deals with actually running queries and such. The reason I have the DatabaseController class is because I can store the open connection handle to the static member _sqlconn and so the connection is only ever opened once, and Database objects simply use the same handle, even though the program can and will create many Database objects.
But again, is this actually necessary? Should I simply be opening a new connection within the main Database class, every time an object is created? There was another site and thread I found that apparently, what the .NET Framework does is even though you maintains a connection pool for you, so even though you might be opening and disposing of several connections, they aren't truly closed. Is this truly so, and does that apply to both desktop and windows 8 apps?
It is recommended to keep connections 'open' only for as long as they are needed i.e. as long as the unit of work requires.
As you have suggested, when you 'close' them they are not actually closed, but just returned to the pool for re-use by other threads/applications. This applies to any ADO.NET data provider.
If your application is single threaded, then you probably won't notice pooling occurring, but in situations when there are many threads requiring data-access then the quicker connections are returned to the pool then the quicker they can be re-used by other threads.
When using sqlite you have to know how the engine was compiled. See here http://sqlite.org/threadsafe.html. It's important since sqlite behaves differently depending on the threading model used.
You might have to have logic where the connection is shared between all code that want to access the databse. You might also need code which prevents different threads from working with the Sqlite db simultaneously.
Most other ADO.NET providers supports connection pooling which means that the connections are reused when you invoke the Close() method.
Back to basics.
I have an application written in c# and I am using the sqlClient to connect to database.
I have several methods and I usually open the connection in a try catch block
try{
**open connection**
//Mehod1()
//Method2()
........
}catch(exception){
//Do something
}finally{
**close connection**
}
The Problem is that there are a lot connections in pool.
I am using master page and in master page I am loading the menu from database (different menu for each user).
Then in main pages I open again a connection to get the rest data.
In the middle of the page it may be a method that need again to connect to database.
My Question is
Is this a good practise?
Am I doing something wrong?
Is there a better practise to avoid multiple connections?
What about singleton pattern?
Thanks in advance
SOLUTION
I found the reason!!!
I had forgot to close a connection.
I was sure that I had close it, but
sometimes you can't be so sure.
Thanks everyone for your responses
Since the connection is pooled you don't need to "reuse" it in different methods.
I use the following code:
using(SqlConnection connection = new SqlConnection("your-connectionstring"))
{
// Do your stuff here...
}
Using is just a short hand way of writting try-catch-finally. It is used for disposable objects.
And this can go into each method.
EDIT: Using the connection from the pool is not hurting performance either. All connection information are cached anyway. So just use the SqlConnection on an atomic level.
It's a good thing though to have the ConenctionString handling in a more generic way...
Using() as said above is a good way to new up a new object of a class that implements IDisposable. But with that being said , you cannot leave you connection open once you done. You have finite number of connection in the pool and leaving a connection unclosed can starve other SPIDs which are waiting for active connection which will finally timeout. So you should
Always have atomic and small transactions .
Close when done.
There is DAAB (data access application block) from Microsoft Enterprise Library which can be used as helper to open and close connections + do many other DB related tasks easily. Here it is
http://msdn.microsoft.com/en-us/library/cc511547.aspx
Probably you didn't dispose your SqlConnections
try this:
using (SqlConnection connection = new SqlConnection(connectionString))
{ }
this syntax will call method Dispose() automatically for you. Using statement details here
UPDATE:
A bit more info about this methods you may find here: Close, Dispose
Basically the difference is that method Dispose() called method Close(), but before it is cleaning some resources and removing connection from the pool details here.
As you see Dispose() doing a bit more than Close(). So if you going to reuse connection later use method Close() if not destroy that completely using method Dispose() which is automatically getting called if you using the syntax above.
I was trying to explain to someone why database connections implement IDisposable, when I realized I don't really know what "opening a connection" actually mean.
So my question is - What does c# practically do when it opens a connection?
Thank you.
There are actually two classes involved in implementing a connection (actually more, but I'm simplifying).
One of these is the IDbConnection implementation (SQLConnection, NpgsqlConnection, OracleConnection, etc.) that you use in your code. The other is a "real" connection object that is internal to the assembly, and not visible to your code. We'll call this "RealConnection" for now, though its actual name differs with different implementations (e.g. in Npgsql, which is the case where I'm most familiar with the implementation, the class is called NpgsqlConnector).
When you create your IDbConnection, it does not have a RealConnection. Any attempt to do something with the database will fail. When you Open() it then the following happens:
If pooling is enabled, and there is a RealConnection in the pool, deque it and make it the RealConnection for the IDbConnection.
If pooling is enabled, and the total number of RealConnection objects in existence is larger than the maximum size, throw an exception.
Otherwise create a new RealConnection. Initialise it, which will involve opening some sort of network connection (e.g. TCP/IP) or file handle (for something like Access), go through the database's protocol for hand-shaking (varies with database type) and authorise the connection. This then becomes the RealConnection for the IDbConnection.
Operations carried out on the IDbConnection are turned into operations the RealConnection does on its network connection (or whatever). The results are turned into objects implementing IDataReader and so on so as to give a consistent interface for your programming.
If a IDataReader was created with CommandBehavior.CloseConnection, then that datareader obtains "ownership" of the RealConnection.
When you call Close() then one of the following happens:
If pooling, and if the pool isn't full, then the object is put in the queue for use with later operations.
Otherwise the RealConnection will carry out any protocol-defined procedures for ending the connection (signalling to the database that the connection is going to shut down) and closes the network connection etc. The object can then fall out of scope and become available for garbage collection.
The exception would be if the CommandBehavior.CloseConnection case happened, in which case it's Close() or Dispose() being called on the IDataReader that triggers this.
If you call Dispose() then the same thing happens as per Close(). The difference is that Dispose() is considered as "clean-up" and can work with using, while Close() might be used in the middle of lifetime, and followed by a later Open().
Because of the use of the RealConnection object and the fact that they are pooled, opening and closing connections changes from being something relatively heavy to relatively light. Hence rather than it being important to keep connections open for a long time to avoid the overhead of opening them, it becomes important to keep them open for as short a time as possible, since the RealConnection deals with the overhead for you, and the more rapidly you use them, the more efficiently the pooled connections get shared between uses.
Note also, that it's okay to Dispose() an IDbConnection that you have already called Close() on (it's a rule that it should always be safe to call Dispose(), whatever the state, indeed even if it was already called). Hence if you were manually calling Close() it would still be good to have the connection in a using block, to catch cases where exceptions happen before the call to Close(). The only exception is where you actually want the connection to stay open; say you were returning an IDataReader created with CommandBehavior.CloseConnection, in which case you don't dispose the IDbConnection, but do dispose the reader.
Should you fail to dispose the connection, then the RealConnection will not be returned to the pool for reuse, or go through its shut-down procedure. Either the pool will reach its limit, or the number of underlying connections will increase to the point of damaging performance and blocking more from being created. Eventually the finaliser on RealConnection may be called and lead to this being fixed, but finalisation only reduces the damage and can't be depended upon. (The IDbConnection doesn't need a finaliser, as it's the RealConnection that holds the unmanaged resource and/or needs to do the shut-down).
It's also reasonable to assume that there is some other requirement for disposal unique to the implementation of the IDbConnection beyond this, and it should still be disposed of even if analysing the above leads you to believe its not necessary (the exception is when CommandBehavior.CloseConnection passes all disposal burden to the IDataReader, but then it is just as important to dispose that reader).
Good question.
From my (somewhat limited knowledge) of the "under-the-hood" working of a SQL Connection, many steps are involved, such as:
The Steps Under the Hood
Physical socket/pipe is opened (using given drivers, eg ODBC)
Handshake with SQL Server
Connection string/credentials negotiated
Transaction scoping
Not to mention connection pooling, i believe there is some kind of alogrithm involved (if the connection string matches one for an already existing pool, the connection is added to the pool, otherwise new one is created)
IDiposable
With regards to SQL Connections, we implement IDisposable so that when we call dispose (either via the using directive, or explicity), it places the connection back into the connection pool. This is in stark contrast with just the plain old sqlConnection.Close() - as all this does is close it temporarily, but reserves that connection for later use.
From my understanding, .Close() closes the connection to the database, whereas .Dispose() calls .Close(), and then releases unmanaged resources.
Those points in mind, at the very least it is good practice to implement IDisposable.
Adding to answers above... The key is that upon "opening the connection" resources may be allocated that will take more than standard garbage collection to recover, namely an open socket/pipe/IPC of somekind. The Dispose() method cleans these up.