-
Notifications
You must be signed in to change notification settings - Fork 37
Transaction model
To support undo and concurrent editing, we update our model following a set of "transactions".
The server is our cluster of web servers. They communicate with a database, another cluster.
The model is all the data in a single document set. It is too big to be copied between the database and the server, so only the database can see the complete model. But the server, being a crafty proxy, can query for any parts of the complete model that it needs, whenever it wants, so as far as the client is concerned, the server model is complete. The client model is at the lower end of the food chain.
We alter the model (client, server or complete) via a transaction (client transaction, server transaction and database transaction). Conceptually, transactions are applied to models one-at-a-time, that is, in serial. So each transaction brings a model from one version to the next.
Transactions behave differently in the client, server and database. They all share the concept of a delta, which contains all the information we need to transition the model from one version to another.
A delta can be too large for the client to transmit to the server and too large for the server to transmit to the database. (Tagging 5 million documents, each with an 8-byte ID, will consume 40MB.) So we introduce the notion of a compressed delta, which is quick to transmit (i.e., "add tag 3 to node 7"), and a expanded delta, which is what the database works with.