14.2.2. Cache, database and synchronisation: mechanisms
We briefly characterise these mechanisms.
14.2.2.1. Cache
State is cached in MonadPerspectives. This is a Monad based on ReaderT and Aff. Through ReaderT we have access to an AVar. This AVar holds a record with fields. We modify the contents of the AVar in order to change state. This arrangement allows us to modify state asynchronously.
14.2.2.2. Database
Couchdb stores JSON documents. Each Context or Role instance is serialised as a JSON document. Instances are stored in a database in Couchdb whose name is constructed from the unique string that identifies a user, thus allowing a single Couchdb instance to host data for many users. An important facet of Couchdb is its synchronisation mechanism. This in turn depends on versioning. In order to be able to change a document in Couchdb, one must send the current revision string along to the http request. To speed up the process, we keep the revision string in cache for documents we’ve retrieved from Couchdb before.
14.2.2.3. Synchronisation
Synchronisation is a two-step process:
-
the PDR of a user who changed state compiles a Transaction of such changes and sends them to relevant other users (in fact, each user receives a Transaction tailored to his perspectives);
-
the PDR of these other users processes the Transaction. This involves checking whether the sender was authorised to perform the changes. If so, it loads the changed entities in cache (if they weren’t there before) and applies the changes. Finally it saves them to its own Couchdb instance.