I wanted to know which approach is better, to have a single odbc connection shared among a series o threads, using a mutex to make sure that there are no concurrence problems, or to have one per thread and not use mutex. I don't see any substantial advantage in any of them, but maybe there are things in the odbc implementation i'm missing.
I tried to look for similar questions but couldn't find anything, sorry if it's been answered before
The ODBC Driver Manager already provides Connection Pooling: https://msdn.microsoft.com/en-us/library/ms716319(v=vs.85).aspx
Connection pooling enables an application to use a connection from a
pool of connections that do not need to be reestablished for each use.
In short: If a Connection is released by your application, and connection pooling is enabled, the driver manager will maybe not close the connection immediately, but keep it for some time open. If your application requests a new connection to be opened, the driver manager might return such an already open connection from its pool.
So: I would not care about do all the locking within your threads, but just enable connection pooling and let each driver use its own connection.
Note that you can either enable connection pooling on a process level or for each environment handle - see the remarks in the documentation:
Enables connection pooling by calling SQLSetEnvAttr to set the
SQL_ATTR_CONNECTION_POOLING environment attribute to
SQL_CP_ONE_PER_DRIVER or SQL_CP_ONE_PER_HENV.
I think that it depends on what you want to achieve with your implementation. Having only one shared connection with a lot of threads will result in threads being blocked and waiting for the connection to be available. This can decrease the performance. If you have a large number of threads, I'd rather create a sort of connection pool that handles the creation, usage and closure of connections.
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)
Does anyone know if there is a way to force abort connection that is being established in background thread? Or at least define connect timeout?
A couple of notes
Leaving background thread running and just forgetting about it is not an option.
Went through source code and available properties - could not find anything related to the question.
Please be aware that FireDAC (Data Access Library) only describes the Technology from Delphi to simplify accessing Data on several Databases.
To define a Timeout on your connection, the Database Connection has to Support that.
Here is the Describtion for a Connectiontimeout in, for example, an Interbase Connection via FireDAC.
http://docwiki.embarcadero.com/Libraries/Berlin/en/FireDAC.Phys.IBBase.TFDIBService.ConnectTimeout
What does it do? How does it work? Why am I supposed to test the database connection before "borrowing it from the pool"?
I was not able to find any related information as to why I should be using it. Just how to use it. And it baffles me.
Can anyone provide some meaningful definition and possibly resources to find out more?
"test-on-borrow" indicates that a connection from the pool has to be validated usually by a simple SQL validation query defined in "validationQuery". These two properties are commonly used in conjunction to make sure that the current connections in the pool are not stale (no longer connected to the DB actively as a result of a DB restart, or timeouts enforced by the DB, or whatever other reason that might cause stale connections). By testing the connections on borrow, the application can automatically reconnect to the DB using new connections (and dropping the invalid ones) without a manual restart of the app and thus preventing DB connection errors in the app.
You can find more information on jdbc connection pool attributes here:
https://tomcat.apache.org/tomcat-8.0-doc/jdbc-pool.html#Common_Attributes
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.
I have a client-server app that uses .NET SqlClient Data Provider to connect to sql server - pretty standard stuff. By default how long must connections be idle before the connection pooling manager will close the database connection and remove it from the pool? What setting if any controls this?
This MSDN document only says
The connection pooler removes a connection from the pool after it has been idle for a long time, or if the pooler detects that the connection with the server has been severed.
A few years ago the answer beneath was the situation, but now it's changed so you can refer to the source and write up a summary :)
Old answer
This excellent article tells us what we need to know, using reflection to reveal the inner workings of connection pooling.
From how I understand it, 'closed' connections are cleaned up periodically on a semi-random interval. The cleanup process runs somewhere between every 2min and 3min 50s, but it needs to run twice before a 'closed' connection will be properly closed. Therefore after 7min 40s of being 'closed' the underlying sql connection should be properly closed, but it could be as short as 2min. At the time of writing the first connection pool created in a process would always have a timer interval of 3min 10s, so you'd normally see sql connections being closed somewhere between 3min 10s and 6min 20s after you call Close() on the ADO object.
Obviously this uses undocumented code so could change in future - or could even have changed since that article was written.
Please go through this:
http://msdn.microsoft.com/en-us/library/system.data.sqlclient.sqlconnection.connectionstring%28VS.80%29.aspx
The part
"The following table lists the valid
names for connection pooling values
within the ConnectionString."
seems to be of your interest.