dg99
dg99

Reputation: 5663

Chronic stale results using MySQLdb in Python

My Python program queries a set of tables in a MySQL DB, sleeps for 30 seconds, then queries them again, etc. The tables in question are continuously updated by a third-party, and (obviously) I would like to see the new results every 30 seconds.

Let's say my query looks like this:

"select * from A where A.key > %d" % maxValueOfKeyFromLastQuery

Regularly I will see that my program stops finding new results after one or two iterations, even though new rows are present in the tables. I know new rows are present in the tables because I can see them when I issue the identical query from interactive mysql (i.e. not from Python).

I found that the problem goes away in Python if I terminate my connection to the database after each query and then establish a new one for the next query.

I thought maybe this could be a server-side caching issue as discussed here: Explicit disable MySQL query cache in some parts of program

However:

  1. When I check the interactive mysql shell, it says that caching is on. (So if this is a caching problem, how come the interactive shell doesn't suffer from it?)

  2. If I explicitly execute SET SESSION query_cache_type = OFF from within my Python program, the problem still occurs.

Creating a new DB connection for each query is the only way I've been able to make the problem go away.

How can I get my queries from Python to see the new results that I know are there?

Upvotes: 25

Views: 6389

Answers (4)

Kudehinbu Oluwaponle
Kudehinbu Oluwaponle

Reputation: 1145

I can not say exactly why this issue occurs but I have tested 3 solutions that solved the problem

  1. Create a new mysql connection (and a new cursor) before running each query

    cnx = mysql.connector.connect(**config2)
    csr = cnx.cursor(named_tuple=True, buffered=True)
    

I am not sure this is recommended practice but it solves the problem

  1. Commit - either by setting autocommit to true or by manually committing after each query
  2. Understand that the problem only occurs with transaction storage engines, so if it is not important to use transactional, you can set the table you are querying to a non transactional type like MyISAM - probably the easiest option

I didn't add setting the transactional isolation level to READ COMMITED because I haven't tried it and someone else claimed it didn't work for him

Upvotes: 0

GuruMatics
GuruMatics

Reputation: 399

You may want to check the transaction isolation level of your database. The behavior you describe is what you may expect if it is set to REPEATABLE-READ. You may want to change it to READ-COMMITTED.

Since the original poster of the problem mentions that he is merely querying the database, it cannot be a commit that was forgotten. Inserting a commit seems to be a workaround though since it causes a new transaction to begin; and a new snapshot may need to be established. Still, having to insert a commit before every select doesn't sound like good programming practices to me.

There is no python code to show since the solution lies in correctly configuring the database.

DO check MySQL documentation at http://dev.mysql.com/doc/refman/5.5/en/set-transaction.html.

REPEATABLE READ
This is the default isolation level for InnoDB. For consistent reads, there is an important difference from the READ COMMITTED isolation level: All consistent reads within the same transaction read the snapshot established by the first read. This convention means that if you issue several plain (nonlocking) SELECT statements within the same transaction, these SELECT statements are consistent also with respect to each other. See Section 14.3.9.2, “Consistent Nonlocking Reads”.

READ COMMITTED
A somewhat Oracle-like isolation level with respect to consistent (nonlocking) reads: Each consistent read, even within the same transaction, sets and reads its own fresh snapshot. See Section 14.3.9.2, “Consistent Nonlocking Reads”.

Checking the configured isolation level:

>mysql > SELECT @@GLOBAL.tx_isolation, @@tx_isolation;
+-----------------------+-----------------+
| @@GLOBAL.tx_isolation | @@tx_isolation  |
+-----------------------+-----------------+
| REPEATABLE-READ       | REPEATABLE-READ |
+-----------------------+-----------------+
1 row in set (0.01 sec)

Setting the transaction isolation level to READ-COMMITTED

mysql> SET GLOBAL tx_isolation='READ-COMMITTED';
Query OK, 0 rows affected (0.00 sec)

mysql> SET SESSION tx_isolation='READ-COMMITTED';
Query OK, 0 rows affected (0.00 sec)

mysql> SELECT @@GLOBAL.tx_isolation, @@tx_isolation;
+-----------------------+----------------+
| @@GLOBAL.tx_isolation | @@tx_isolation |
+-----------------------+----------------+
| READ-COMMITTED        | READ-COMMITTED |
+-----------------------+----------------+
1 row in set (0.01 sec)

mysql>

And run the application again …

Upvotes: 17

Eric Pauley
Eric Pauley

Reputation: 1779

This website and this website contain information on the same problem. In order to keep your tables up to date, you must commit your transactions. Use db.commit() to do this.

As mentioned by the post below me, you can remove the need for this by enabling auto-commit. this can be done by running db.autocommit(True)

Also, auto-commit is enabled in the interactive shell, so this explains why you didn't have the problem there.

Upvotes: 26

Jonathan
Jonathan

Reputation: 2014

You can enable auto-commit automatically in MySQLdb! Try the following:

conn = MySQLdb.Connect("host", "user", "password")
conn.autocommit(True)

This gives you the same behavior that you are used to in the interactive shell.

Upvotes: 10

Related Questions