Caching with RWDBReader
In
Caching with RWDBInserter, we saw how to use the caching mechanism of class
RWDBInserter. With class
RWDBReader, we can use a similar caching mechanism when receiving data from a database server. To enable the caching features of
RWDBReader, we pass a cache size of
n > 1 to its producer method. The following example shows how to construct a reader with a cache size of
5.
Example 16 – Caching with RWDBReader
RWDBConnection aConn = aDb.connection();
RWDBReader reader = aSelector.reader(aConn, 5); //1
int aInt;
while (reader()) //2
{
reader >> aInt; //3
//process aInt
}
In
//1, we produce an
RWDBReader of cache size
5 from an
RWDBSelector.
In
//2, we use
operator() of
RWDBReader to fetch data from the database server; in this case, it fetches five rows, since we set the cache size to
5.
In
//3, we shift the first row of the
RWDBReader object's cache into the variable
aInt. After processing the value, we return to step
//2, where
operator() is called a second time. On this second call to
operator(), the
RWDBReader returns without a network hit to fetch data, as the second row is already fetched from the database server. We then shift the second row in the
RWDBReader object's cache into the application variable
aInt in
//3.
This pattern is repeated until the sixth call to
operator(). At the time of this call, the
RWDBReader has exhausted its internal cache of rows, and must request a new set of rows from the database server. As you can see, by using caching, the
RWDBReader must make only one network trip for every five rows read.
RWDBReader producer methods accept a cache size of 0 by default, which results in the selection of an acceptable default cache size by the Access Module you are using. So for most Access Modules, caching is used at some default level even if you do not pass a cache size parameter. You need to explicitly pass a cache size only if you want a specific, non-default value. Please check your Access Module User's Guide for more information.
