The puirpose of this document is to explain how
DODS handles caching.
General Notes
- Pro: Caches are faster
In most cases, queries that find their answers in the cache will run faster than queries
that must hit the database.
- Pro: Caches can save memory
An advantage to using caches is that, for a given row in a table, application memory will
contain only a single DO representing that row. This is because Query objects will always
return a DO in the cache, even if the Query object had to hit the database to put the DO
in the cache.
- Con: The "dirty write" problem
- The "dirty write" problem, cached scenerio
If thread 1 and thread 2 have both done a query that returned the same DO from the cache,
they could both call the same setXxx() method on the DO, overwriting each other's changes.
In applications where this scenerio is possible, care must be taken to control updates to
DOs that are retrieved from a cache.
- The "dirty write" problem, uncached scenerio
A variation on the "dirty write" problem also exists when the DO is not cached.
For a DO class that is not cached, every query constructs new DO objects to return, even
if identical DO objects have been returned before. It is thus possible to have 2 DO
objects that represent the same row. Calling setXxx() and save() on one of the DOs means
the other DO contains old data. Fortunately, the version column in the first DO will be
incremented, which prevents save() from being called on the other DO.
In applications where this scenerio is possible, care must be taken to prevent multiple
threads from trying to update the same row through multiple DOs.
Caching Modes
There are 3 possible caching modes for a given DO class:Fully Cached
Partially Cached
If a DO is "fully cached" or "partially cached", the DO class will
contain a static Hashtable that contains the cache. The cache will be keyed by the
ObjectId (OID) values of the DOs.
Fully Cached DOs
If a DO class is "fully cached", then when the class is loaded, a query is
automatically run which gets all rows from the table and puts corresponding DOs in the
cache.
This is most appropriate for DOs representing read-only data that is needed often by the
application.
The refreshCache() method will empty the current cache and reload it by again reading all
the rows in the table.
Partially Cached DOs
If a DO class is "partially cached", no automatic query is run. As the
application queries those DO objects, they are added to the cache. The Query class will
first check the DO cache before hitting the database. A "partial cache" best
supports queries specifying a value for a column that contains unique values, like Social
Security Number:
// PersonDO is "partially cached"
PersonQuery pq = new PersonQuery();
pq.setQuerySSN( "123456789" );
PersonDO uniquelyIdentifiedPerson = pq.getDOArray();
Since a "partial cache" will not always contain all rows in the table, a
query against a non-unique column may return some but not all matching DOs. An example is
the unqualified query:
PersonQuery pq = new PersonQuery();
// This query is not restricted by any setQueryXxx() method calls.
// It will return the entire contents of the PersonDO cache,
// which may well not be all the rows in the person table.
PersonDO[] perhapsNotEverybody = pq.getDOArray();
If PersonDO is "partially cached", to find everyone named "Joe"
(when they might not all be in the cache), force the query to hit the database:
PersonQuery pq = new PersonQuery();
pq.hitDatabase();
// PersonDO.FirstName obviously won't have unique values.
pq.setQueryFirstName( "Joe" );
PersonDO[] allJoes = pq.getDOArray();
The refreshCache() method will empty the cache, leaving it to be filled by the results
of future Query objects.
SQL JOIN operations
The Query classes generated by DODS perform queries on a single table. There is no way to
perform a JOIN operation using Query objects. Likewise, there is no way to use DO class
caches to perform JOINs.
JOINs can be performed using the QueryBuilder class.
Or, a VIEW can be created to perform the JOIN, and a DO/Query class pair created to
represent the VIEW.
|