We Keep Coding

C# WinForm Oracle sessions hangs after connection closed

I'm using multiple connections in different methods, but when I close the connection, the connection sessions hangs in database sessions as inactive until I terminate the .exe file. I'm using connections in using statement like:
using(OracleConnection con = new OracleConnection(constring))
{
con.Open();
}
And I also tried to close and dispose the connection manually and use OracleConnection.ClearPool(con) and OracleConnection.ClearAllPools() but none of them works.
the reference im using:
System.Data.OracleClient version 2.0.0.0
connection string
Data Source = ip/db; User Id = user; Password=pw;

This behaviour is normal because if you Dispose(); a connection the ConnectionPool from Oracle doesn't really destroy the connection but set the status to 'free'. So the next time you open a connection, you don't really open a new connection, you just look for a 'free' connection in your ConnectionPool and use this one. If no free Connection exists, a new one will be created.
This behaviour garants you a better performance because Open/Close Connections cost much afford.
If you use:
using(OracleConnection con = new OracleConnection(constring))
{
}
or
con.Close();
This is the same as you use Dispose();. Using just make sure that the Dispose is called on the end of your using block. That's why using only works on objects which implement IDisposable.
So far ok...But why doesn't OracleConnection.ClearAllPools()close the connections? It does but Oracle directly create a new Connection, so that your ConnectionPool is filled up to your MinPool-Size. This is the reason why BigTallJosh's code:
"Min Pool Size = 0; Max Pool Size = 16; Incr Pool Size = 2; Decr Pool
Size = 1; Validate Connection = False; Connection Lifetime = 0;
stop this behaviour. A Min Pool Size of 0 will stop automatic creation of new connections.
Here you can find a good explanation about ClearAllPools(); Method.
So to finally answer your question. Set the MinPoolSize=0 and after that call connection.ClearAllPools();. This should work.

C# - SQL Connection won't close

I'm making a C#program that interacts with some SQL Server databases. The problem is if I connect to a database (dbA) and then close this connection and open another one to another database (dbB) and then do a Restore of dbA, the SqlException triggers saying that database (dbA) is in use. However if I execute the program and connect only to dbB, I can restore the other databases without problem, is like the first connection is kept stored. Anyway here is the code where the connection should open and close:
private bool CheckConnection()
{
bool res = false;
string conString = string.Empty;
if (!String.IsNullOrEmpty(serverBox.Text) && !String.IsNullOrEmpty(dbBox.Text))
{
conString = ConcatConString(dbBox.Text);
using (SqlConnection conn = new SqlConnection(conString))
{
conn.Open();
if (conn.State == ConnectionState.Open)
{
res = true;
}
}
}
return res;
}

ADO.NET uses connection pooling to reuse expensive connection objects. When you close a connection, any existing transactions are rolled back, its server-side state is reset and it's placed in the connection pool awating for the next Open command.
To the server though, that still counts as a server connection when you try to take such drastic actions as shutting down the server, restoring the database etc. That means that you have to take explicit action and tell the server that it's OK to proceed.
In this case, you need to set the database to SINGLE USER mode, perform the restore operation then bring it back to MULTI USER mode, eg:
ALTER DATABASE [MyDB] SET SINGLE_USER WITH ROLLBACK IMMEDIATE
RESTORE DATABASE [MyDB] ...
ALTER DATABASE [MyDB] SET MULTI_USER
That's what SSMS does by the way, when you check the "Close Existing Connections to Database" option when restoring
You can also use WITH ROLLBACK AFTER xx SECONDS if you want give some time to existing connections to finish. In this case though, you are going to overwrite the database.

Closing a connection does not close it at the database, it just returns the connection to the pool maintained by ADO.Net. Normally I would never suggest this but it seems you may have a legitimate case for disabling connection pooling.
In the connection string set the Pooling attribute to no or false and the connection should actually close on the server.
You can observe how it works by running sp_who2 in SSMS with connection pooling enabled or disabled in the following code:
class Program
{
static void Main(string[] args)
{
SqlConnectionStringBuilder bldr = new SqlConnectionStringBuilder();
bldr.IntegratedSecurity = true;
bldr.InitialCatalog = "YourDB";
bldr.DataSource = "(localdb)\\YourServer";
bldr.Pooling = false; //Comment and uncomment this and run sp_who2
using (SqlConnection con = new SqlConnection(bldr.ConnectionString))
{
con.Open();
}
}
}
Update
Don't do this unless your program is the only thing connecting. I got the impression that the program was specifically for restoring databases. If you have other clients on the databases then this will tank performance.

Closing connection and number of connections to SQL Server DB

I have a ASP.net application in which I do a query on a SQL Server Database. When the query ends, I do the following :
reader.Close();
reader.Dispose();
conn.Close();
conn.Dispose();
And still when I go on SQL Server and does :
SELECT
DB_NAME(dbid) as DBName,
COUNT(dbid) as NoOfConnections,
loginame as LoginName
FROM
sys.sysprocesses
WHERE
dbid > 0
GROUP BY
dbid, loginame
I can see the 'NoOfConnections' that keeps increasing while I have closed the connection and there is a moment where I'll get an error because I have over 100 connections opened. How do I close the connections properly?

SQL Server connection pooling will cache connections. You can clear all connection pools with this:
conn.ClearAllPools();
For more info, see here.
To clear the connection pool for a specific connection, you can use the ClearPool method. For example:
conn.ClearPool();
For more info, see here.
You can configure the size of the connection pool through the connection string, for example:
Provider=SQLOLEDB;Data Source=ServerName;Integrated Security=SSPI;Min Pool Size=5; Max Pool Size=20;
You can turn off pooling in the connection string also, for example:
Provider=SQLOLEDB;Data Source=ServerName;Integrated Security=SSPI;Pooling=false;
Connection Pooling is on by default, the default size of the connection pool is 100. If the client connection string is the same, the pool will try and use a connection from the connection pool - if it is available. For more see here.

Instead of doing this
reader.Close();
reader.Dispose();
conn.Close();
conn.Dispose();
Why not use using statements? Example, for Connection:
using (var conn = new SqlConnection("YourConnectionString"))
{
//your code here
}
This will close and dispose of the SqlConnection object for you.

Auto-closing TIBCO EMS connections when no longer needed

We're using TIBCO EMS from our ASP.NET 3.5 app for one interface to an external system, and it appears to be working just fine - except that the guys running the other side tells us we're racking up connections like crazy and never closing them....
What I'm doing is routing all TIBCO traffic through a single class with static member variables for both the TIBCO ConnectionFactory and the Connection itself, having been told that constructing them is pretty resource- and time-intensive:
private static ConnectionFactory Factory
{
get
{
if (HttpContext.Current.Application["EMSConnectionFactory"] == null)
{
ConnectionFactory connectionFactory = CreateTibcoFactory();
HttpContext.Current.Application["EMSConnectionFactory"] = connectionFactory;
}
return HttpContext.Current.Application["EMSConnectionFactory"] as ConnectionFactory;
}
}
private static Connection EMSConnection
{
get
{
if (HttpContext.Current.Application["EMSConnection"] == null)
{
Connection connection = Factory.CreateConnection(*username*, *password*);
connection.ExceptionHandler += new EMSExceptionHandler(TibcoConnectionExceptionHandler);
connection.Start();
HttpContext.Current.Application["EMSConnection"] = connection;
}
return HttpContext.Current.Application["EMSConnection"] as Connection;
}
}
Now my trouble is: where and how could I
tell the TIBCO connection to "auto-close" when no longer needed (like with the SqlConnection)
close the TIBCO connection on an error
close the TIBCO connection before our ASP.NET app finishes (or the user logs off)
I don't really seem to find much useful information on how to use TIBCO EMS from the C# / .NET world...... any takers?? Thanks!!

Firstly, I don't understand how you could be running out of connections. Since you're storing the connection in the application, you should only have a single connection for the entire IIS application.
That put aside, I would do the following:
When the connection is retrieved, create the connection as you do now;
After you've created the connection, spin up a background thread;
Set a DateTime to DateTime.Now;
Let the background check (e.g. every second or every 10 seconds) what the difference is between the date you've set and DateTime.Now. If that's longer than a specific timeout, kill the connection and set Application["EMSConnectionFactory"] to null;
When the background thread kills the connection, close the background thread;
Every time the connection gets requested, reset the DateTimetoDateTime.Now`.
This way, the connections should be closed automatically.
Note that you will have to introduce locking. You can use Application.Lock() and Application.Unlock() for this.
Concerning closing on an error: I see that you've attached an exception handler to the connection instance. Can't you close the connection with that?

Access to SQL DB in multithread server app

In my server application I want to use DB (SQL Server) but I am quite unsure of the best method. There are clients whose requests comes to threadpool and so their processing is async. Every request usually needs to read or write to DB, so I was thinking about static method which would create connection, execute the query and return the result. I'm only afraid whether opening and closing connection is not too slow and whether some connection limit could not be reached? Is this good approach?

IMHO the best is to rely on the ADO.NET connection pooling mechanism and don't try to handle database connections manually. Write your data access methods like this:
public void SomeMethod()
{
using (var connection = new SqlConnection(connectionString))
using (var command = connection.CreateCommand())
{
connection.Open();
command.CommandText = "SELECT Field1 FROM Table1";
using (var reader = command.ExecuteReader())
{
while(reader.Read())
{
// do something with the results
}
}
}
}
Then you can call this method from wherever you like, make it static, call it from threads whatever. Remember that calling Dispose on the connection won't actually close it. It will return it to the connection pool so that it can be reused.

Surprised that no one mentioned connection pooling. If you think you are going to have a large number of requests, why not just setup a pool with a min pool size set to say 25 (arbitrary number here, do not shoot) and max pool size set to say 200.
This will decrease the number of connection attempts and make sure that if you are not leaking connection handles (something that you should take explicit care to not let happen), you will always have a connection waiting for you.
Reference article on connection pooling: http://msdn.microsoft.com/en-us/library/8xx3tyca.aspx
Another side note, why the need to have the connection string in the code? Set it in the web.config or app.config for the sake of maintainability. I had to "fix" code that did such things and I always swore copiously at the programmer responsible for such things.

I have had exactly the same problem like you. Had huge app that i started making multithreaded. Benefit over having one connection open and being reused is that you can ask DB multiple times for data as new connection is spawned on request (no need to wait for other threads to finish getting data), and if for example you loose connection to sql (and it can happen when network goes down for a second or two) you will have to always check if connection is open before submitting query anyway.
This is my code for getting Database rows in MS SQL but other stuff should be done exactly the same way. Keep in mind that the sqlConnectOneTime(string varSqlConnectionDetails) has a flaw of returning null when there's no connection so it needs some modifications for your needs or the query will fail if sql fails to establish connection. You just need to add proper code handling there :-) Hope it will be useful for you :-)
public const string sqlDataConnectionDetails = "Data Source=SQLSERVER\\SQLEXPRESS;Initial Cata....";
public static string sqlGetDatabaseRows(string varDefinedConnection) {
string varRows = "";
const string preparedCommand = #"
SELECT SUM(row_count) AS 'Rows'
FROM sys.dm_db_partition_stats
WHERE index_id IN (0,1)
AND OBJECTPROPERTY([object_id], 'IsMsShipped') = 0;";
using (var varConnection = Locale.sqlConnectOneTime(varDefinedConnection))
using (var sqlQuery = new SqlCommand(preparedCommand, varConnection))
using (var sqlQueryResult = sqlQuery.ExecuteReader())
while (sqlQueryResult.Read()) {
varRows = sqlQueryResult["Rows"].ToString();
}
return varRows;
}
public static SqlConnection sqlConnectOneTime(string varSqlConnectionDetails) {
SqlConnection sqlConnection = new SqlConnection(varSqlConnectionDetails);
try {
sqlConnection.Open();
} catch (Exception e) {
MessageBox.Show("Błąd połączenia z serwerem SQL." + Environment.NewLine + Environment.NewLine + "Błąd: " + Environment.NewLine + e, "Błąd połączenia");
}
if (sqlConnection.State == ConnectionState.Open) {
return sqlConnection;
}
return null;
}
Summary:
Defined one global variable with ConnectionDetails of your SQL Server
One global method to make connection (you need to handle the null in there)
Usage of using to dispose connection, sql query and everything when the method of reading/writing/updating is done.

The one thing that you haven't told us, that would be useful for giving you an answer that's appropriate for you is what level of load you're expecting your server application to be under.
For pretty much any answer to the above question though, the answer would be that you shouldn't worry about it. ADO.net/Sql Server provides connection pooling which removes some of the overhead of creating connections from each "var c = new SqlConnection(connectionString)" call.