home *** CD-ROM | disk | FTP | other *** search
/ Il CD di internet / CD.iso / SOURCE / CONTRIB / MBASE / MBASE51.TAR / mbase51 / tech / chapter.5 < prev    next >
Encoding:
Text File  |  1993-09-04  |  2.7 KB  |  50 lines
  1. Tech Chapter 5 - Internal cache                                   MetalBase 5.1
  2. -------------------------------------------------------------------------------
  3.  
  4. Since MetalBase is not written around a client-server model, records cannot
  5.    be cached in between function calls... if they were did, there's a good
  6.    possibility that another process would modify the relation while we were
  7.    idle, invalidating our cache.
  8.  
  9. Actually, that's a rather inaccurate argument.  The truth is that records could
  10.    conceivably be cached between operations, with only one improvement
  11.    required: when an operation which uses the cache is performed, a strobe
  12.    byte should be incremented somewhere in the relation... and the calling
  13.    process should store the new number in the appropriate relation* structure.
  14.    The cache would be flushed but not cleared after each operation.  When the
  15.    next request is made, the number would be checked; if they weren't the same,
  16.    the cache would be cleared, otherwise, no operation took place and the cache
  17.    should still be valid.  To prove useful, though, this would require that
  18.    each index have its own cache...
  19.  
  20. But that's for a later release, and I'm getting away from the point of this
  21.    chapter.  Because we don't/can't cache between operations, we instead
  22.    cache data during the slowest internal operation: rebalancing.
  23.  
  24. The nature of rebalancing is that it reads and modifies a single record many,
  25.    many times over.  To speed up this process, MetalBase reads records through
  26.    a cache; if the record requested doesn't exist in the cache, it is read in;
  27.    at that point, a pointer into the cache is returned.  Any modifications
  28.    are made to the cache, which is flushed when it becomes full or when the
  29.    operation requires it.
  30.  
  31. This is a very basic cache--rebalancing doesn't require that the actual records
  32.    be checked, just the pointers for the indices.  The top-of-index pointer
  33.    is also cached.
  34.  
  35. The entire cache (500 records' worth of it, as 5.1 is shipped) is available for
  36.    each index to be worked upon in turn.  Unfortunately, this means two things:
  37.  
  38.       1st: If a system such as the one I rambled on about earlier is
  39.               implemented, only a single index could have information
  40.               retained.  This would have to change.
  41.  
  42.       2nd: MetalBase makes two or three passes through the list of
  43.               indices before completing an add, update or delete operation;
  44.               the first passes are read-only, but the data that is read in
  45.               does not remain in the cache during the next stage.
  46.  
  47. See the comments in the source code [mb_cache.c] for more information regarding
  48.    the implementation of MetalBase's internal cache.
  49.  
  50.