I'm facing a very difficult problem with a web a application that I'am implementing with a group of developers. We are using Simple Data to connect to a Oracle database but after several connection or when we have a lot of users the connection pool gets full and the application doesn't work any more. The problem is that Simple Data opens the connection to make the transactions but it never close the connection so the application stops the transactions, we saw at the simple data documentation that it says that althought in code it's not necessary to close the connection the simple data do it itself but is not true.
We already try to change the number of available connection from 100 to 50 per user, but the problem continues, another solution that we implemented was to open a share connection, but it didn't work either. The question is, Is there a way in code to Close the connections in the simple data?.
var db=Database.Open();
return db.Table.FindById(Id:2);
In that sample code, you can see that I open the connection, but there is no method to close it. If someone can help me with this problem I'll be grateful. Thank you.
Info:
We are using, NancyFx framework, C# an Oracle11g database.
Old post but if anyone wondering about it! ...
As the docs on page (http://simplefx.org/simpledata/docs/pages/Start/OpeningAConnection.html) saya at the last line
Simple.Data is quite aggressive in closing connections and holds no open connections to a data store by default, so you can keep the Database object returned from the Open*() methods hanging around without worrying.
Related
I am writing a UWP app using the Windows.Devices.WiFi to basically get a lists of networks. Everything was working fine when I retrieved the information a time or two. However, I wanted to put the code into a timer so I can report regularly. Once I did this, I got "an attempt was made to establish a session to a network server, but there are already too many sessions established to that server."
I am not sure what is establishing connections as I am just trying to read the information. I am not even calling the ConnectAsync calls.
Can anyone help me out? I need to know what to dispose, or close, etc.
Update: Further analysis, I am finding that the call to FindAllAdaptersAsync multiple times is causing this issue.
I decided to cache up the list of adapters by only calling FindAllAdaptersAsync once. Thanks for the idea Henk. This seemed to fix my issue for now. However, I think that it is a bug with FindAllAdaptersAsync. I would think you should be able to call this as much as you like, unless maintaining the network connection is necessary every time. Or at least a way to free them up.
I currently have a working program that is monitoring a few SQL tables and transferring data to MySQL tables. Essentially, I have a loop that checks every 30 seconds. My main concern is that I currently need to close and open the connection every time I loop. The reason for this is because I was getting errors about multiple transactions. When I close my connections, I also need to dispose the connection. I thought that disposing the transactions would have solved this problem, but I was still getting errors about multiple transactions.
This all seems to be working fine but I was wondering if there was a better way to do this without closing the connection.
I am not sure about your errors but it seems that you have to increase the number of connections to the remote computer. Have a look here http://msdn.microsoft.com/en-us/library/system.net.configuration.connectionmanagementelement.maxconnection.aspx
Also you can try to do is use only one connection to realize multiple SQLs.
If it is doesn't help then please provide your code to check it...
Were you committing your transactions in your loop? transaction.Commit() ... that could have been the issue... Hard to say with no code. No need to worry about opening and closing connections anyways since ADO.NET uses connection pooling behind the scenes. You only actually 'open' a connection the first time, after that is kept open in the pool to be used again. As others have said though, Post some code!
I have those group of CheckBox Lists and Repeaters (about 8 controls needed to be loaded from my db) and for each control, I have a method in my DataAccess Layer to select the information and get it back to my control.
But There's a page that I need all those 8 controls to be loaded on the same time .. so each method will be a trip to the db and I understand that's what affects the performance. So can I have like a new method to create the connection and open it, then I can call multiple methods to access the db and load the info then close the connection at the end.
Any ideas if those 8 connections are okay for performance ? and what do you think about this idea and how can it be applied in a practical way ?
Unless your app is going to be on a high-traffic website, I wouldn't worry about it until it becomes an issue. It's relatively simple to go back and fix it later should problems arise, but this sounds like a case of premature optimization, to be honest.
If you're using the native SqlClient to access your database, using the exact same connection string, they will share a connection pool. . By default, connection pooling is enabled in ADO.NET. Unless you explicitly disable it, the pooler optimizes the connections as they are opened and closed in your application.
So based on your question if you do:
using (SqlConnection...)
{
// all your data calls
}
or 7 separate calls, each opening and closing (or using "using") as #Tim Coker mentioned, any differences in performance will be minimal
Edit: There are some dated articles on MSDN that do say "Open a connection as late as possible and close it as soon as possible", so you could do a rapid series of method calls that each open and quickly close the connection, but again, will be sharing the same pool anyway.
If the data is read-only, you could cache it.
Then, each trip to the database will only be made once.
There is very little overhead when you open and close a connection, so you should not worry about that.
I'm hearing that is better to have one connection open upon app start up and closing it when the app shuts down.
What kind of issue can occur having multiple connections ?
Any articles out there that it is best practices to have one connection?
What are your experience with sql ce?
In our SQL CE 3.5 / Compact Framework 3.5 application, we open a connection at startup and keep it open until the application is closed. The database is required on almost every user-interaction in the application and keeping the connection open is faster than opening and closing it on demand.
All data updates are performed in transactions. We Commit the transactions using the CommitMode.Immediate option. This ensures that data changes are immediately flushed to the file, minimising the potential for data loss.
It really depends. For performance, SQL CE works best if there is always a live connection to the database, as the engine doesn't have to build up everything every time you connect.
Having a single connection, however, leads to lazy flushiong of data to the file, and a higher likelihood of data loss or corruption in the event of a catastrophic failure.
I tend to open a "dummy" connection to the database at app startup and have that connection always open but rarely or never actually used. This keeps the engine "primed" if you will. THen for actual data access I use a separate connection and manage state based on what activity I'm doing, typically leaving it open across multiple queries (a pseudo transaction if you will), but not leaving it open indefinitely.
I have an SQL server on a server at home (which is an Atom processor with 1GB ram), and i'm using it to store data for one or two of my applications. I was wondering if i should create a DataContext object when the program starts then hold onto it for the entire life of the app, or only create the connection when necessary. What happens if the application dies suddenly? does the connection get cleaned up?
Unless you're handing DataContext object an already open SqlConnection, DataContext will automatically close the database connection after the completion of a database operation anyway. So it won't keep the connection open. You can see this by looking at DataContext class in Reflector or you can read ASP.NET MVC Tip #34: Dispose of your DataContext(or Don't) blog post. So even if your DataContext object continues to live, there should not be any open database connection.
If you're handling the database connection outside of DataContext and keeping it open, then you really should not do this. Generally, you should create and use resources when and where you need them including DataContext object. There is no need to keep a database connection open without any demand for it, close it so that it gets released back into the pool to serve another database connection request. As I said, if you're letting DataContext handle the database connection, you don't need to do anything special as far as the database connection is concerned.
If your application crashes suddenly and terminates, you should be ok since everyhing will die including open database connections and the underlying connection pool associated with your application domain.
Bring up the data context when you need it and get rid of it when you're done.
Having one global datacontext means you have to pass it around to everything that needs it. (Every method you write that needs database access has an extra parameter in its signature).
Having a single global datacontext is also just going to become a pain if you ever decide to multi-thread one of your apps.
Have you looked at SQL connection pooling in .NET? Have a look at the article at http://msdn.microsoft.com/en-us/library/8xx3tyca%28VS.80%29.aspx. Connection pooling takes care of all the dirty work for you and automatically cleans up after itself if an error occurs in your program. It's pretty efficient at re-using connections so there is very little overhead in re-using the connections (creating the first connection when your program starts still has the same cost). It might be overkill for small applications but it's probably a good habit to get into for larger projects.