somewhere in my application I have a memory leak, and I suspect it's because a database connection isn't being correctly closed or disposed of...
in asp.net, is there a way to detect how many database connections there currently are open?
Connection.Close never gets called in my app is the problem - NHibernate handles all of that, as far as I'm aware.
To detect open connections, you can use database management tool to connect to your test database and check active sessions there.
You can also use Performance Monitor to monitor open connections for .NET Framework applications.
Related
How to manage the session in oracle?
Is oracle session affect the performance of the database?
Is single oracle session can be sharable between different users?
Relation between odp.net connection object and oracle session?
If connection object is closed in odp.net then session from oracle is also get released?
You can monitor and kill sessions, otherwise there is normally no need to manage them. Connecting an user creates one as soon as the first command or query is executed; disconnecting may or may not destroy one (if pooling is involved, it might just idle while the middle tier releases it to the pool); see also
What is Oracle Session?
The session alone, as such, is not an expensive object and won't have a noticable effect on performance. The transaction volume and query load that is actually executed during a session, will.
No. There is the concept of session multiplexing (https://docs.oracle.com/cd/B28359_01/server.111/b28310/manproc001.htm) but that's about network load optimization.
in practice, one connection will correspond to one session. More sessions can be opened during one connection though: https://asktom.oracle.com/pls/asktom/f?p=100:11:115616585537006::::P11_QUESTION_ID:5671284058977
for all 11g and 12c I worked with using ODP.NET, this was the case. as stated in 1), when pooling is enabled, you may see a number of idle sessions remain for a certain amount of time after all connections in ODP.NET are already closed.
This question is related to my old question .
1) I have a vb.net application which requires connections to some databases.So now if i open multiple instance of same application(exe files) then it uses different connection or uses multiple connection. So can i make it to use single connection?
2) I heard about Appdomain(An AppDomain provides a layer of isolation within a process) . Does it help in making the connection to be drawn from same pool and make optimal use of resources?
This article has something related to it.
Different processes (your case #1) do not (and cannot) share database connections, each connection is unique to the process.
I do not know whether connection pools are per process or per-appdomain.1 But it is unlikely to make much difference. The model that you should be aiming for is to create, use and then close connections around each functional database operation. Do not try and keep them open, rather try and keep them closed. This maximises the re-use opportunities for re-use.
Unless you have a particular will a few excess connections over what is theoretically needed the default pooling while avoiding holding connections open will just work.
1 As connections are reset before being returned from the pool it would be rather hard to determine which of these is the case. Perhaps a test program that had one app domain open, use and close one connection before another app domain repeated the process and see if one or two connections to the database were established.
Each AppDomain would have its own Connection Pool, so no I don't think using AppDomains would help in your case.
I was was wondering if anyone knows if it is possible to have multiple applications share the same database connection
e.g if I have an application which opens a connection to a database
then I start another application which needs to connect to the same database - so instead of having 2 connections open, I use the connection from the first app which is already open
thereby only having one connection open
the reason I am asking this is because I am developing a system which is built from seperate exe's instead of one big one - but they all access the same database
any help would be appreciated
thanks
IMHO you can sharing the same connection string, but sharing the same physical DB connection between 2 applications unaware of eachother would not be such a good idea. How would you handle locking, concurrency, transaction boundaries, etc?
If the reason for this is to reduce DB licensing costs or connection limits, it might be worthwhile to look at a shorter connection lifespan (i.e. apps connect and disconnect from the DB as needed, rather than keeping the connection open for the lifespan of the app)
If you really want to pursue sharing of a connection, you might look at splitting your app into having a single common back end (e.g. Windows or WCF service) which manages a singleton db connection.
You'll probably want to create a separate assembly containing the logic to connect to the database (via configurable connection string) and reference the assembly for each project that needs to use it. Note, they won't be 'sharing' the same physical database connection, rather you'll be sharing the code and logic between the two applications, it will still be two separate database connections which you can't get around but it's also not a bad thing, it's just the way it has to be :) The only way you could share the same connection is if the two apps were actually in the same app and I gather that's not what your talking about since you mentioned it has two executable's, so two separate programs.
Connection pooling should work for you. If multiple exes need a database connection at the same time, you'll want more than one connection, but once those connections are released back to the pool, another exe can pick them up and re-use them.
I think this is often included in the ODBC/database drivers without any extra effort on your part, but it has never become an issue for me so I'm not sure.
You should not (and cannot) share a connection between two applications. You can share the same connection string, and turn on Connection Pooling, which may re-use connections for you, but you shouldn't depend on it.
As Capital G said, you should put all your database access logic in a separate assembly/layer, or even a WCF Service / Web Service.
Currently there is discussion as to what are the pros and cons of having a single sql connection architecture.
To elaborate what we are discussing is, at application creation open a sql connection and at application close or error closing the sql connection. And not creating another connection at all, but using just that one to talk with the DB.
We are wondering what the community thinks.
Close the connection as soon as you do not longer need it for an undefined amount of time. By doing so, the connection returns to the connection-pool (if connection pooling is enabled), and can be (re)used by someone else.
(Connections are expensive resources, and are sometimes limited).
If you keep hold on a connection for the entire lifetime of an application, and you have multiple users for that application (thus multiple instances of the app, and multiple connections), and if your DB server is limited to have only x number of concurrent connections, then you could have a problem ....
See also best practices for ado.net
Follow this simple rule... Open connection as late as possible and close it as soon as possible.
I think it's a bad idea, for several reasons.
If you have 10,000 users using your application, that's 10,000 connections open constantly
If you have to restart your Sql Server, all those 10,000 connections are invalidated and your application will suddenly - assuming you've included reconnect logic - be making 10000 near-simultaneous re-connect requests.
To expand on point 1, you should close connections as soon as you can because otherwise you're using up a finite resource for, potentially, an inifinite period of time. If you had Sql Server configured to allow a maximum of 10,001 simultaneous connections, then you can only have 10,001 users running your application at any one time. If you open/close connections on demand then your application will scale much further as the likelihood of all the active users making use of the database simultaneously is, realistically, low.
Under the covers, ADO.NET uses connection pooling to manage the connections to the database. I would suggest leaving it up to the connection pool to take care of your connection needs. Keeping a connection open for the duration of your application is a bad idea.
I use a helpdesk system called Richmond Systems that uses one connection for the life of the application, and as a laptop user, it is a royal pain in the behind. Even when I carry my laptop around open, the jumps between the wireless access points are enough to drop the DB conenction. The software then complains about the DB conenction, gets into an error state and won't close. It has to be killed manually from Task Manager.
In short, DON'T HOLD OPEN A DATABASE CONNECTION FOR LONGER THAN NECESSARY.
But on the flip side, I'd be cautious about opening and closing connections too often. This is a lot cheaper with connection pooling than without, but even with pooling, the pool manager may decide to grow or shrink the pool, turning it back into an expensive operation.
My general rule is to open a connection when the user initiates some action, do the work, then close the connection before waiting for the next user input. For any given "Update" button click or whatever, I'll generally have only one connection. But you definately do not want to keep connections open while waiting for user input if you can at all help it for all the reasons others have mentioned. You could literally wait for days before the user presses another key or touches another button -- what if he leaves his computer on and goes on vacation? Tying up a resource for unpredictable amounts of time like that is bad news. In most cases, the elapsed time waiting for user input will far exceed the time doing actual work.
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.