I have a small but significant query. I'll give a similiar use case but simplified, it does however cover my question.
Let's User A connects to the SQL Server 2000 database and we get a connection from the pool.
User A sets dateformat DMY. Finishes and the connections is released back to the pool.
User B comes along, connects with the same string and gets the same connection from the pool, sets the dateformat MDY, finished and returns the connection.
User A reconnects and gets the same connection, what is the dateformat ?
Is it re initialised on returning to the pool?
Do the connections retain there settings?
When the connection is removed from the pool where does a new connection take it's initial settings?
If you didn't program the pooling mechanism yourself. Its more likely that the connection goes back to its initial state before going into the pool. Moreover, there will be a configuration option where programmers can define or customize the behavior of the connection and the pool. And that is where the new connection gets its setting from. Otherwise, there must be a default settings given by the provider.
Related
I have this 'issue' since a long time and I am really wondering if this is just me or if there actually is a way of preventing the following:
UPDATED
In Visual Studio, when using the Server Explorer on a .mdf database, in a Entity Framework Code first approach project whenever I am opening the Database manually to see the data of certain tables (clicking on Show table data), it seems that even when I close the connection like this:
the database connection stays open somehow in the background.
I am getting "... the Database is currently in use ..." error if wanting to debug afterwards, after closing the connection, even when restarting the solution.
When I close all sqlservr.exe process(es) in the Task manager that does the trick.
Note that this is a local solution and a local database (.mdf) i am using for testing purposes. Nothing or no one else is using this solution.
I am quite sure this is not the behavior it should have right?
What am I doing wrong or what can I do to not have this behavior if this is not by default?
Thank you in advance for any feedback!
Include the "Pooling" flag in the connect string set to false:
Pooling=False
However, this might not be the best option in a productive environment:
Connection pooling reduces the number of times that new connections must be opened. The pooler maintains ownership of the physical connection. It manages connections by keeping alive a set of active connections for each given connection configuration. Whenever a user calls Open on a connection, the pooler looks for an available connection in the pool. If a pooled connection is available, it returns it to the caller instead of opening a new connection. When the application calls Close on the connection, the pooler returns it to the pooled set of active connections instead of closing it. Once the connection is returned to the pool, it is ready to be reused on the next Open call. (...) SQL Server Connection Pooling (ADO.NET)
I have a simple code, using Kemal Crystal Framework with a database pooled connection but only mantain connection on startup, and each request decrease by one of connection to mysql.
As a DB::Database.using_connection says on docs:
yields a connection from the pool the connection is returned to the
pool when the block ends
Must not be closed !!!
https://gist.github.com/valenciaj/534b5c820462db808eac13ba6c392614
You must set max_idle_pool_size DB::Database parameter to mantain opened connections.
I have a problem in WSO2 DSS, the database connection timeout is occurring after a few hours, then I have to stopping and starting the DSS to work.
The DSS version is 2.5.1
the database server is sql server
can help me ? Thank
Have you properly configured your datasource that's used in the dataservice descriptor file to enable "validationQuery" parameter to "SELECT 1" (validation query can vary depending on the RDBMS type used but for SQL server you can use the aforementioned query) and "testOnBorrow" parameter to "true"?
To give you a bit of context on the issue, any RDBMS type by default has a connection timeout value defined. For example, MySQL has a default timeout of 8 hours by default. When connection pooling is used in an application, the connections are kept in the pool once they are created without physically closing to reuse them. However, after the aforementioned period of time, the connections become stale and you have to validate the connections before using them. This is done by specifying a validation query which will be executed whenever a pooled connection is reused. and the "testOnBorrow" parameter comes handy as, when specified, it will validate the pooled connections when they are borrowed from the conneciton pool.
Cheers,
Prabath
I have 3 servers set up for SQL mirroring and automatic failover using a witness server. This works as expected.
Now my application that connects to the database, seems to have a problem when a failover occurs - I need to manually intervene and change connection strings for it to connect again.
The best solution I've found so far involves using Failover Partner parameter of the connection string, however it's neither intuitive nor complete: Data Source="Mirror";Failover Partner="Principal" found here.
From the example in the blog above (scenario #3) when the first failover occurs, and principal (failover partner) is unavailable, data source is used instead (which is the new principal). If it fails again (and I only tried within a limited period), it then comes up with an error message. This happens because the connection string is cached, so until this is refreshed, it will keep coming out with an error (it seems connection string refreshes ~5 mins after it encounters an error). If after failover I swap data source and failover partner, I will have one more silent failover again.
Is there a way to achieve fully automatic failover for applications that use mirroring databases too (without ever seeing the error)?
I can see potential workarounds using custom scripts that would poll currently active database node name and adjust connection string accordingly, however it seems like an overkill at the moment.
Read the blog post here
http://blogs.msdn.com/b/spike/archive/2010/12/15/running-a-database-mirror-setup-with-the-sqlbrowser-service-off-may-produce-unexpected-results.aspx
It explains what is happening, the failover partner is actually being read from the sql server not from your config. Run the query in that post to find out what is actually being used as the failover server. It will probably be a machine name that is not discoverable from where your client is running.
You can clear the application pool in the case a failover has happened. Not very nice I know ;-)
// ClearAllPools resets (or empties) the connection pool.
// If there are connections in use at the time of the call,
// they are marked appropriately and will be discarded
// (instead of being returned to the pool) when Close is called on them.
System.Data.SqlClient.SqlConnection.ClearAllPools();
We use it when we change an underlying server via SQL Server alias, to enforce a "refresh" of the server name.
http://msdn.microsoft.com/en-us/library/system.data.sqlclient.sqlconnection.clearallpools.aspx
The solution is to turn connection pooling off Pooling="false"
Whilst this has minimal impact on small applications, I haven't tested it with applications that receive hundreds of requests per minute (or more) and not sure what the implications are. Anyone care to comment?
Try this connectionString:
connectionString="Data Source=[MSSQLPrincipalServerIP,MSSQLPORT];Failover Partner=[MSSQLMirrorServerIP,MSSQLPORT];Initial Catalog=DatabaseName;Persist Security Info=True;User Id=userName; Password=userPassword.; Connection Timeout=15;"
If you are using .net development, you can try to use ObjAdoDBLib or PigSQLSrvLib and PigSQLSrvCoreLib, and the code will become simple.
Example code:
New object
ObjAdoDBLib
Me.ConnSQLSrv = New ConnSQLSrv(Me.DBSrv, Me.MirrDBSrv, Me.CurrDB, Me.DBUser, Me.DBPwd, Me.ProviderSQLSrv)
PigSQLSrvLib or PigSQLSrvCoreLib
Me.ConnSQLSrv = New ConnSQLSrv(Me.DBSrv, Me.MirrDBSrv, Me.CurrDB, Me.DBUser, Me.DBPwd)
Execute this method to automatically connect to the online database after the mirror database fails over.
Me.ConnSQLSrv.OpenOrKeepActive
For more information, see the relevant links.
https://www.nuget.org/packages/ObjAdoDBLib/
https://www.nuget.org/packages/PigSQLSrvLib/
https://www.nuget.org/packages/PigSQLSrvCoreLib/
I was wondering if anyone knows how to set up connection pooling for Sitecore 6 running on SQLServer 2005 ?
And is this a good idea to setup on a Sitecore solution? Or probably more correct, will there be any problems if setup incorrectly?
Any other comments or tips about this are also greatly appreciated.
The answers from Sitecores support:
By default, connection pooling is
enabled in ADO.NET (it means that we
don't need any connection string
parameters to enable it, parameters
are needed only to disable or to tune
the connection pooling). Thats why
there are no connection pooling
parameters in the default connection
strings. For more information please
refer to the following MSDN articles:
http://msdn.microsoft.com/en-us/library/system.data.sqlclient.sqlconnection.connectionstring.aspx
http://msdn.microsoft.com/en-us/library/8xx3tyca.aspx
If you wish to tune the Database
Connection Pooling, you can add
appropriate parameters to the
connection strings.
Second reply after I asked some more about it:
Please see
http://msdn.microsoft.com/en-us/library/8xx3tyca%28v=vs.80%29.aspx
When a connection is first opened, a
connection pool is created based on an
exact matching algorithm that
associates the pool with the
connection string in the connection.
If MinPoolSize is either not specified
in the connection string or is
specified as zero, the connections in
the pool will be closed after a period
of inactivity. However, if the
specified MinPoolSize is greater than
zero, the connection pool is not
destroyed until the AppDomain is
unloaded and the process ends.
Maintenance of inactive or empty pools
involves minimal system overhead.
Following connection strings
parameters can be applied.
# Max Pool Size - specifies the
maximum size of your connection pool.
Default is 100. Most Web sites do not
use more than 40 connections under the
heaviest load but it depends on how
long your database operations take to
complete. # Min Pool Size - initial
number of connections that will be
added to the pool upon its creation.
Default is zero; however, you may
chose to set this to a small number
such as 5 if your application needs
consistent response times even after
it was idle for hours. In this case
the first user requests won't have to
wait for those database connections to
establish. # Pooling - controls if
your connection pooling on or off.
Default as you may've guessed is true.
I hope this helps others.
The only mentioning about negative impacts I'm aware about is this.