an mru cache
I've now implemented a most receintly updated object cache. Remember, the database already has a most receintly referenced cache for retaining the N most receintly referenced objects. The new cache writes dirty objects to disk when there are too many dirty objects--and it always chooses the dirty object which has not been updated for the longest time. This then solves the problem of long-running transactions that update more objects than can be held in memory.
I've also been thinking that the database can have some of the functionality of a version control system--it can support both tags (snapshots) and branches. But I want a bit more flexibility in the control structures than can be directly implemented in a copy-on-write (COW) database.
Seems to me like a good time to implement a hash table, though I don't think having one big area of disk space dedicated for this purpose would conform very well with a COW database. But we could have a heirarchy of hash tables--that would be a good fit.
Once we have a hash table, we can create identifiers which reference an object. And then we can have multiple references to the same object. This will add a lot of flexibility, as the handles we use to reference an object must be the sole reference to that object. The hash table then would be used to map an identifier (a name) to a handle or object.
Note that we can use the table object that has already been implemented as the leaf nodes of the tree. So we only need to define the interior nodes (hash nodes) to implement our heirarical hash.
0 Comments:
Post a Comment
<< Home