Preventing queries caching in MySQL

Question

I\'m using the tomcat connection pool via JNDI resources.

In the context.xml:

Answer 1

As documented under Consistent Nonlocking Reads:

If the transaction isolation level is REPEATABLE READ (the default level), all consistent reads within the same transaction read the snapshot established by the first such read in that transaction. You can get a fresher snapshot for your queries by committing the current transaction and after that issuing new queries.

[ deletia ]

If you want to see the “freshest” state of the database, use either the READ COMMITTED isolation level or a locking read:

SELECT * FROM t LOCK IN SHARE MODE;

You can set the default transaction isolation level in Tomcat via its Resource@defaultTransactionIsolation attribute.

Answer 2

The connection pool does not have anything to do with data caching (unless you specifically configure it that way). It's best practice to use a connection pool for database access to prevent runaway connections (e.g. hitting the database with too many simultaneous connections) and to reuse connections that have been opened once (typically establishing a connection is quite expensive, thus they get utilized again). You'll also want the statements themselves (as PreparedStatement) to be cached, as the next expensive operation for a database is to determine the execution plan. (This is independent of the actual result caching)

Have you analyzed if your cached data actually comes from mysql or if you're caching on application level?

Also, make sure that your insert & update transactions are actually committed, otherwise there obviously won't be any change and the data looks like it's cached.

Answer 3

RESET QUERY CACHE only clears the query cache.

FLUSH TABLES closes all tables (after flushing any unwritten data) and also clears the query cache.

Clearing the cache cannot cause anything like the problem you are having. All it does is forcing subsequent queries to actually fetch the data from the tables (until these results are cached again).

Please note, the query cache is guaranteed to never show outdated data. Any committed write to any table referred to by a query in the cache removes such query from the cache. If you see outdated data, then another external mechanism must be in action. For example, many ORM's do some row caching at some stage, and such mechanism may be broken, or may produce unexpected results if not used exactly as intended.

And anyways, if either query_cache_size = 0 or query_cache_type = OFF (or 0), then the query cache is disabled.