DBI database handle with AutoCommit set to 0 not returning proper data with SELECT?

Question

This is a tricky one to explain (and very weird), so bear with me. I will explain the problem, and the fix for it, but I would like to see if anyone can explain why it works the

Answer 1

I think that when you turn autocommit off, you also start a transaction. And, when you start a transaction, you may be protected from other people's changes until you commit it, or roll it back. So, if my semi-informed guess is correct, and since you're only querying the data, add a rollback before the sleep operation (no point in holding locks that you aren't using, etc):

$dbh->rollback;

Answer 2

I suppose you are using InnoDB tables and not MyISAM ones. As described in the InnoDB transaction model, all your queries (including SELECT) are taking place inside a transaction.

When AutoCommit is on, a transaction is started for each query and if it is successful, it is implicitly committed (if it fails, the behavior may vary, but the transaction is guaranteed to end). You can see the implicit commits in MySQL's binlog. By setting AutoCommit to false, you are required to manage the transactions on your own.

The default transaction isolation level is REPEATABLE READ, which means that all SELECT queries will read the same snapshot (the one established when the transaction started).

In addition to the solution given in the other answer (ROLLBACK before starting to read) here are a couple of solutions:

You can choose another transaction isolation level, like READ COMMITTED, which makes your SELECT queries read a fresh snapshot every time.

You could also leave AutoCommit to true (the default setting) and start your own transactions by issuing BEGIN WORK. This will temporarily disable the AutoCommit behavior until you issue a COMMIT or ROLLBACK statement after which each query gets its own transaction again (or you start another with BEGIN WORK).

I, personally, would choose the latter method, as it seems more elegant.