In traditional webservers you would have a SQL connection pool and persistent connection to the database.
But I am thinking of creating my entire application as Azure Functions.
Will the functions create a new connection the SQL server everytime its called upon?
Azure Functions doesn't currently have SQL as an option for an input or output binding, so you'd need to use the SqlClient classes directly to make your connections and issue your queries.
As long as you follow best practices of disposing your SQL connections (see this for example: C# SQLConnection pooling), you should get pooling by default.
Here's a full example of inserting records into SQL from a function: https://www.codeproject.com/articles/1110663/azure-functions-tutorial-sql-database
Although this is already answered, I believe this answer can provide more information.
If you are not using connection pool then probably you are creating connection every time function is invoked. Creating connection has associated cost, for warmed up instances it is recommended to use connection pool. max number of connection should also be chosen cautiously since there can be couple of parallel functions app running (as per plan).
This is example of connection pool.
Related
Is there any way to communicate with a socket using SQL language? (Why?) Assume that, I manually open SQL Server Management Studio and open a table and then insert a record manually (by manually I want to emphasize on the absence of any middleware in between). At this moment the business demands for signaling the inserted record to another context (as either notification, or report (i.e. grid view, etc)).
The solution that I have in mind is to write the inserted record to a file and using another application monitor the file for change (Emphasizing again that I don't wanna do this through a middleware at all) , but this method is not a standard way to achieve this requirement and it is more of a workaround.
Is there any standard way to signal changes using pure SQL Server syntax/features?
You can have a SQLCLR routine that calls out to "something", whenever a change happens. Where I work we ue that for real-time streaming of dats from SQL Server to RabbitMQ. In your case you would have to have a trigger on the table, which calls the routine.
In our case we always change data through stored procedures, so our procedures call the SQLCLR routine.
You could also use Service Broker and External Activation. In our case we chose not to do it as the performance was not good enough.
If you want, I have a blog-post about the SQL Server -> RabbitMQ integration using SQLCLR. Obviously it doesn't have to be Rabbit, we've also done it through socket connections etc. So if you're interested, the post is here.
Hope this helps!
Niels
I have been under the understanding that database connections are best used and closed. However with SQLite Im not sure that this applies. I do all the queries with a Using Connection statment. So it is my understanding that I open a connection and then close it doing this. When it comes to SQLite and optimal usage, is it better to open one permament connection for the duration of the program being in use or do I continue to use the method that I currently use.
I am using the database for a VB.net windows program with a fairly large DB of about 2gig.
My current method of connection example
Using oMainQueryR As New SQLite.SQLiteCommand
oMainQueryR.CommandText = ("SELECT * FROM CRD")
Using connection As New SQLite.SQLiteConnection(conectionString)
Using oDataSQL As New SQLite.SQLiteDataAdapter
oMainQueryR.Connection = connection
oDataSQL.SelectCommand = oMainQueryR
connection.Open()
oDataSQL.FillSchema(crd, SchemaType.Source)
oDataSQL.Fill(crd)
connection.Close()
End Using
End Using
End Using
As with all things database, it depends. In this specific case of sqlite, there are two "depends" you need to look at:
Are you the only user of the database?
When are implicit transactions committed?
For the first item, you probably want to open/close different connections frequently if there are other users of the database or if it's all possible that more than process will be hitting your sqlite database file at the same time.
For the second item, I'm not sure how sqlite specifically behaves. Some database engines don't commit implicit transactions until the connection is closed. If this is the case for sqlite, you probably want to be closing your connection a little more often.
The idea that connections should be short-lived in .Net applies mainly to Microsoft Sql Server, because the .Net provider for Sql Server is also able to take advantage of a feature known as connection pooling. Outside of Sql Server this advice is not entirely without merit, but it's not as much of a given.
If it is a local application being used by only one user I think it is fine to keep one connection opened for the life of the application.
I think with most databases the "Best used and closed" idea comes from the perspective of saving memory by ensuring you only have the minimum number of connections need open.
In reality opening the connection can be a large amount of of overhead and should be done when needed. This is why managed server infrastructure (weblogic etc.) promotes the use of connection pooling. In this way you have N connections that are utilizable at any given time. You never "waste" resources but you also aren't left with the responsibility of managing them at a global level.
SQL connection – I planned to create one sql connection object inside my own singleton class (say connectionmanager with Reference counting for ‘SQL connection object’ which is a member of the class) and open/close the connection whenever needed. As I like to give high importance for performance. And my application is a desktop based application accessing a remote database server (SQL server 2008), and will use only one connection string, 50 concurrent desktop users may access db server. Please advice.
As like many articles say if the answer is “Connection pooling is taken care by ado.net” – Does that mean that scope of connection pool is entire life of Application instance? Or is it in the scope of SQLConnection object?
Connection pooling is taken care by ado.net” – Does that mean that scope of connection pool is entire life of Application instance?
Yes. Read MSDN article - SQL Server Connection Pooling (ADO.NET)
Connections are pooled per process, per application domain, per
connection string and when integrated security is used, per Windows
identity. Connection strings must also be an exact match; keywords
supplied in a different order for the same connection will be pooled
separately.
The scope of the connection string. Change the string, a new connection pool is created.
related:Multiple Queries on single connection
In a Enterprise application, Is having a single connection execute for different inputs is better than disposing connections after their every execution? btw this is .net 2.0 and Sql 2005 i am talking about but the question applies to all database systems.
It is generally better to just open and dispose connections when you need them. Let connection pooling do its job.
I have an application that is deployed on tomcat on server A and sends queries to a huge variety of SQL Server databases on an server B.
I am concerned that my application could overload this SQL Server database server and would like some way to preventing it making requests to connect to any database on that server if some arbitrary number of connections were already in existence and unclosed.
I am looking at using connection pooling but am under the impression that this will only pool connections to a specific database on the SQL Server server, I want to control the total of these combined connections that will occur to many different databases (incidentally I can only find out the names of individual db's dynamically as they change day to day). Will connection pooling take care of this for me, are am I looking at this from the wrong perspective?
I have no access to the configuration of the SQL Server server.
Links to tutorials or working examples of your suggested solution are most welcome!
Have you considered using DBCP? See here for more info
You're correct. A database pool will limit connections to either the database, or to all databases, depending on how the pool is configured.
Here are several open source packages that implement database connection pools. One of them probably does what you want.
connection pooling ... this will only pool connections to a specific database on the mssql server
AFAIK, this is correct. Your connection pool will only limit the number of connections to the specific database it is defined for.
want to control the total of these combined connections that will occur to many different databases
I dont think you can control the number of connections to all databases from the pool. You've written you don't have access to change things on the MSSQL server. so creating SYNONYMs to the various databases on MSSQL itself is not an option.
You can write your own class within the application, say a ConnPoolManager, which has an internal counter prior to getting and releasing Connections from any of the pools.
This class should cache all the JNDI lookups to each pool.
For the app to get a connection to ANY pool, it goes through the ConnPoolManager and if the counter shows the maxlimit is not yet crossed, only then does it fetch the connection.
Else it throws some exception for you to try later.
There might be a design pattern for this on the lines of Business Delegate.
Having said that, I think a bigger problem for you will be
incidentally I can only find out the names of individual db's dynamically as they change day to day
since you will be expected to create new or edit the connection pool settings in Tomcat each day? This is a maintenance nightmare in the future.