When you run a basic ColdFusion query, when does ColdFusion actually log out of the database? When does the query actually close? My understanding is that when you have multiple users being authenticated at the same time, it maintains it's connection and uses a new thread for a new user. But I am struggling to find any documentation as to when it actually closes. Is it when the page is finished rendering or is it directly after the query execution?
Any help on this matter would be greatly appreciated. We are running ColdFusion 9 Standard with SQL Server 2008.
My understanding it that, by default, ColdFusion won't log out of the database at a particular time. It uses a connection pool, so when you make a query, coldfusion takes a connection from it's pool of connections (creating a connection if none were present), executes the query, then hands the connection back to the pool, ready for more requests. Connections will eventually be closed when they've been inactive for long enough (20 minutes by default, set by the Timeout setting in ColdFusion DataSource admin).
I think the strict answer to your question is: 20 minutes since the last use of that connection, but that's hard to determine
Related
The scenario:
I'm testing out a project written by another engineer in Go to interface with a mysql database. It came to my attention that in Go, whenever a new mysql connection is created, the defaults for this connection are set such that connections never expire.
We recently had a bug in our code that resulted in the proposed statement queue in mysql being completely filled up, resulting in all database requests being denied.
The proposed solution for this bug is to clear out all mysql connections every 24 hours to prevent the proposed statement queue from being filled up.
It is my understanding that our code spawns new connections automatically as needed, and hence clearing out all connections every 24 hours should have no unintended consequences.
The underlying reason why this queue is being filled up seems to be a disconnect between GO language cancelling a connection or request; whereas in mysql, the connection still exists but is only idle. So the proposed solution is to clear out these idle requests and allow them to timeout, using the following code:
conn.SetConnMaxLifetime(24 * time.Hour)
conn.SetConnMaxIdleTime(1 * time.Hour)
conn.SetMaxOpenConns(30)
conn.SetMaxIdleConns(1)
What I seek to understand:
What advantage is there for keeping idle connections, and could there be a situation where more than 1 idle connection is needed?
Are there any unintended consequences that haven't been considered; that could result in a future issue where all database requests get denied?
I have written a web server using Delphi and the Indy TIdHttpServer component. I am managing a pool of TAdoConnection connections to a MySql database. When a request comes in I query my pool for available database connections. If one is not available then a new TAdoConnection is created and added to the pool.
Problems occur when a connection becomes "stale" (i.e. it has not been used in quite some time). I think in this instance the query results in the "MySql has gone away" error.
Does anyone have a method for getting around this? Or would I have manage it myself by one of the following:
Writing a thread that will periodically "refresh" all connections.
Keeping track of the last active query, and if too old pass up using the connection and instead free it.
Two suggestions:
store a 'last used' time stamp with every pooled connection, and if a connection is requested check if the connection is too old - in this case, create a new one
add a validateObject() method which issues a no-op SQL query to detect if the connection is still healthy
a background thread which cleans up the pool in regular intervals: removing idle connections allows to reduce the pool size back to a minimum after peak usage
For some suggestions, see this article about the Apache Commons Pool Framework: http://www.javaworld.com/article/2071834/build-ci-sdlc/pool-resources-using-apache-s-commons-pool-framework.html
I'm working on a node.js application that connects to a MySQL server. The following likely isn't node.js-specific, though.
Currently, my code initializes a MySQL connection at the application start-up, and then it uses that connection every time it needs to make a query.
The issue I'm facing with my approach is that the connection tends to close after a period of time. I'm not sure how long that period of time is, but it seems to be at least several hours. I'm also not sure whether it's caused by inactivity.
In any case, I'm wondering what would be a better approach for managing MySQL connections long-term. Of possible approaches, I've considered:
Simply checking before each query to see whether the connection is still valid. If not, reconnect before executing the query.
Pooling MySQL connections. Would this be overkill for a fairly small application?
Periodically (every hour or so), execute a query, in case this is occurring due to inactivity. However, this doesn't remedy the situation in possible cases not caused by inactivity.
Connect and disconnect before/after queries. Bad idea because of the overhead involved.
I'm leaning toward using one of the first two options, as you might imagine. Which of the options would be most reliable and efficient?
The best practice for Node.js seems to be to use a connection pool. See Node.js MySQL Needing Persistent Connection.
The default timeout for idle connections is 28800 seconds, and is configurable with the wait_timeout variable. See http://dev.mysql.com/doc/refman/5.6/en/server-system-variables.html#sysvar_wait_timeout
As a standard procedure, MySql connection is lost after stated number of hours (default:8) of inactivity. To reconnect to the mysql server after identifying such connection lost I simply do connection = DriverManager.getConnection(url, user, password);
I am not using connection pool and as this trick has not been mentioned in previous connection lost related posts, that makes me wonder if my code will generate any side-effects later? (I say so because testing this code after above instance, I found the sessionlistner is not called after session.invalidate() call.)
You'll loose temporary tables and session settings if your connection drops. It sounds like a connection pool would be useful in your situation.
Depending on how you handle connection object(s), it can create small client-side memory leak for connection object that was lost. But probably this effect will be so small that you will never see any problems from it.
To minimize this risk, you can do something as simple as SELECT 1 every few minutes from your connection during idle time, such that your connection is still considered active (unless your client dies off completely).
I am using NHibernate with mySQL 5 and I am a bit unsure whether NHibernate really closes the connection to mySQL.
This is the code I am using in order to save a Player entity to the database:
using (ISession session = SessionFactory.OpenSession())
{
using (ITransaction transaction = session.BeginTransaction())
{
session.Save(player);
transaction.Commit();
}
}
After running this piece of code, I select the current connection count from the mySQL server using
show status like 'Conn%' ;
and the value is increased every time by 1!
So, inserting the player 10 times (=starting the program 10 times) increases the connection count by 10. But the session.IsClosed property of the NHibernate Session is false.
Do I have to do anything else in order to release the NHibernate resources and close the connection? Are the connections pooled / timed out?
It would be great if anyone could give me a hint.
I'm pretty sure the Connection is being closed. The dispose method on the ISession does just that. So it's unlikely it remains open when exiting the using block.
Also , from what I know the connection is usually opened only when writing/reading to the database . The session may be open, but that doesn't mean the connection is also open.
That, plus the fact that in the mysql documentation, it says that the keyword Connections means :
The number of connection attempts (successful or not) to the MySQL server.
and doesn't say anything about the current state of the connection (open or not), makes me believe that the connection is closed.
PS: you should be using Threads_connected to see open connections.
There is a bug in the MySQL.Data dll in certain versions that was causing this same problem for me. Make sure you update your Connector/NET to the most recent. This solved the problem for me.