ADOdb provides replacement functions that look for cached results, instead of querying the database directly. The names of the methods match the normal method names but with the word 'cache' prepended, e.g.

• cacheGetOne replaces getOne
• cacheExecute replaces execute

The format of the parameters in the cache methods matches that of the normal methods, except for the fact that the parameters are shifted one entry and the first parameter is always the TTL (Time-To-Live) of the query.

The TTL of the query is the amount of time that the results of a query are cached before the results are re-requested from a database. The following sequence of events occurs:

1. A query is issued via one of the ADOdb cache request methods.
2. ADOdb checks to see if the same query has been requested within the TTL value provided.
   1. Note that a statement can always request a 'fresh' result set by providing a 0 (Zero) value TTL.
3. If there is a stored resultset available, it uses that.
4. If there is no result available, or the result is too old, the query is issued to the database, and the resulting recordset is both returned to the requester and stored for later requests.

In real-world applications, the TTL of a query will likely be either extremely short, or extremely long. Take the following examples:

The most common usage for cached queries is returning static data sets, for example a database-provided key-value pair to populate a select list. The permanancy of the data may be such that the TTL of the query requesting it might not need be no more than once per day, in seconds therefore it would be:

60 * 60 * 24 =  86400

Determining the appropriate TTL for a short life request is much more difficult.

As system design has moved towards real-time response, the TTL for short-life requests has decreased. The critical factor has become the frequency with which a recordset is requested, rather than how often the data changes.

For example, in a large system where a single specific query is requested 100 times a minute, but is updated regularly might be configured with a TTL of only 60 seconds. On a well configured system, clearly the results of a request like this would likely be cached by the system or server itself, but a heavily loaded server might benefit from the reduction of preparation and issuing of the query from 100 to 1 times per minute.

If the query itself is complex, or suffers from poor index design, the benefit can be even greater.

/*
* look for a cached query with a life of 2400 seconds
*/
$sql = 'SELECT code,description FROM xref_table';
$db->cacheExecute(2400,$sql);

The size of query results that can be cached by the memcached server is limited by server configuration. The default is quite small. If the query is too large, and debugging is enabled, then an error is displayed.

3849805e4e026b9e7c485999a24a95c6 cache failure: Item with such key doesn't exists on the memcached server.
(this is a notice and not an error)
-----<hr>

(mysqli): SELECT * FROM employees 

-----<hr>
Notice: MemcachePool::set(): Server 192.168.0.78 (tcp 11211, udp 0) failed with:
SERVER_ERROR object too large for cache
(3) in C:\dev\github\mssqlnative-fixes\adodb-memcache.lib.inc.php on line 94
Failed to save data at the memcached server!

Cache write error

PHP Notice:  MemcachePool::set(): Server 192.168.0.78 (tcp 11211, udp 0) failed with:
SERVER_ERROR object too large for cache (3) 
in C:\dev\github\mssqlnative-fixes\adodb-memcache.lib.inc.php on line 94

ADOdb currently has no mechanism for splitting large queries into smaller chunks.