My app is working with MySQL database, to connection I'm using FireDAC components. Last time I have got a network problem, I test it and it is looks like (time to time) it losing 4 ping request. My app return me error: "[FireDAC][Phys][MySQL] Lost connection to MySQL server during query". Now the question: setting fdconnection.TFDUpdateOptions.LockWait to true (default is false) will resolve my problem or make new problems?
TFDUpdateOptions.LockWait has no effect on your connection to the database. It determines what happens when a record lock can't be obtained immediately. The documentation says it pretty clearly:
Use the LockWait property to control whether FireDAC should wait while the pessimistic lock is acquired (True), or return the error immediately (False) if the record is already locked. The default value is False.
The LockWait property is used only if LockMode = lmPessimistic.
FireDAC can't wait to get a lock if it loses the connection, as clearly there is no way to either request the lock or determine if it was obtained. Therefore, changing LockWait will not change the lost connection issue, and it may slow many other operations against the data.
The only solution to your lost ping requests is to fix your network connection so it stops dropping packets. Simply randomly changing options on TFDConnection isn't going to fix networking issues.
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 am developing a back-end with Node.js and MySQL. Sometimes, there are a huge number of queries to be done on the database > 50,000, and I'm using connection pooling. My question is what happens to a query after it is rejected due to the pool being exhausted? Will it be queued until a connection becomes available and then executed? Or it will simply never be executed?
There are indeed similar questions but the answers didn't highlight my point, they just recommended increasing the limit size.
Maybe.
There are options you can set to modify the behavior. See https://github.com/mysqljs/mysql#pool-options
The request may wait in a queue for a free connection, or not. This is based on the option waitForConnections. If you set this option to false, the request returns an error immediately instead of waiting.
If more than queueLimit requests are already waiting, the new request returns an error immediately. The default value is 0, which means there is no limit to the queue.
The request will wait for a maximum of acquireTimeout milliseconds, then if it still didn't get a free connection, returns an error.
P.S.: I don't use Node.js, I just read this in the documentation.
I have been trying to use MySql data with Spotfire, Had a connection established and managed to make a working dxp file. Tried to do the same with a second table and it threw this error
The following error message "Streaming result set com.mysql.jdbc.RowDataDynamic#XXXXXX is still active. No statements may be issued when any streaming result sets are open and in use on a given connection. Ensure that you have called .close() on any active streaming result sets before attempting more queries" comes from MySQL.
afterwards I opened my already working dxp file and the error popped again. It seems I somehow have a connection still open and active but spotfire is suppose to manage the connection as far as I know at least
After looking this up online some people say it's a bug, others say I need to close the connection, but I can't find a solution. Please help
Edit: changing the minimum connections number (which probably closes the open connections) makes ot possible for the dxp to run once but then it fails the second time (after closing and opening)
I have an application which connects to a MySql database using Delphi's TAdoConnection object. This is a very query intensive application. So I create the connection and keep it open to avoid the high resource expense of open/closing database connections. But obviously problems can arise (database restart, network connection failure, etc). So I have built in code to free my database object, recreate it, and reconnect when queries fail.
I have a common function to connect to the database. The relevant code is this:
try
AdoConnection.open;
result := Adoconnection.Connected
except
result := False;
......
end;
I ran some test by turning on and off the MySql database. Everything works fine if the database is off on application startup (i.e. it properly throws an exception). However, if I turn off the database after the application has already successfully connected, subsequent re-connections do not throw exceptions, and additionally falsley report true for AdoConnection.Connected. I am sure the connection object had been freed/recreated first.
It seems there is some sort of caching mechanism going on here (most likely at the hardware/driver level - not application level). Anyone have any ideas?
I observed this also.
Ideas for dealing with it:
If you get an error on running a query then check if it's a connection issue and if so try to reconnect and then run the query again.
If your program uses a timer and waits a while between running batches of queries then perform a simple query (maybe "select now()") before each batch and if this fails then try to reconnect.
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.