In a VB.Net Windows Service I'm currently pooling units of work with:
ThreadPool.QueueUserWorkItem(operation, nextQueueID)
In each unit of work (or thread I'll use for ease of understanding), it will make a couple MSSQL operations like so:
Using sqlcmd As New SqlCommand("", New SqlConnection(ConnString))
With sqlcmd
.CommandType = CommandType.Text
.CommandText = "UPDATE [some table]"
.Parameters.Add("@ID", SqlDbType.Int).Value = msgID
.Connection.Open()
.ExecuteNonQuery()
.Connection.Close() 'Found connections not closed quick enough'
End With
End Using
When running a netstat -a -o on the server I'm seeing about 50 connections to SQL server sitting on IDLE or ESTABLISHED, this seems excessive to me especially since we have much larger Web Applications that get by with 5-10 connections.
The connection string is global to the application (doesn't change), and has Pooling=true defined as well.
Now will each of these threads have their own ConnectionPool, or is there one ConnectionPool for the entire .EXE process?