Resource stores and caching, some explanations

Here are some explanations on resource stores, that I sent in private
email, they might be usefull to others...

-----
A resource store is "something", that given a resource identifier (a
String), returns an instance of some subclass of
w3c.jigsaw.resources.Resource. They are two possible meanings for
"cache" in that context:

a) Because creating a resource might be a costly opertaion, most
resource store implementations will keep track of already loaded
resource (in general through some Hashtable), so:

    . The first query for "foo" in a resource store, a resource instance
    is created, saved in the Hashtable (by adding an entry from "foo"
    to the created instance) and returned.
    . The next time you ask for "foo" the hashtable is checked, if
    already exists, return it, otherwise, proceed as above.

This level of caching ensures that all requests to load "foo" will
return the *same* Java instance for foo (which is not a requirement,
see below).

b) The second level of caching (which always happen), is on a per
resource basis: assuming a resource is an image of something within a
database, the resource can be viewed as a small "cache" for its
attribute values, which are really stored in the database.

Now, I guess a) is easy to understand, it's just general caching. 

b) however is more confusing. If you think of a "write-through" resource,
were setValue() would be implemented as a database request to update
the field of that resource corresponding to the given attribute, then,
you can return different Java instances of foo when queried for the
identifier "foo". This spares you the burden of implementing the
following methods:

- lockResource: is no more needed since resource instances are not
  shared among resource holders (ie the resource can no longer
  disappear behind your back)
- unlockResource (see above)
- lookupResource always returns null
- markModified does nothing


However, in the more common case, where setValue just stores the new
attribute value in the Java instance (without writing through to the
DB) [this is the default behavior of the Resource class], you have to
take care of the "cache-coherency" issue. Note that in this case, the
resource instance has to really be *shared* among all the objects
having a ref to it (ie they have to get the exact same pointer to that
resource)

That's why all the above methods exist: for example
- lockResource: allows someone pointing to that resource to be
  notified when someone else wants that resource to be unloaded.
- markModified: mark that resource as requiring a DB update when this
  will be possible.
etc

Anselm.

Received on Friday, 8 November 1996 05:00:31 UTC