A snapshot is a complete representation of a model at a specific moment in its commit history. A branch is a mutable named reference to a specific commit. A ‘lock’ is an immutable, user-defined named reference to a specific commit. Branches and locks both act as references to commits, so collectively they are called ‘refs’.
...
MMS5 Flexo MMS uses refs to track which commits should have snapshots. Branches are mutable refs that automatically get adjusted to point at the latest commit when an update is made. Locks are immutable refs that can only be created and destroyed. Users can create namespaced locks in order to ‘lock’ access to a particular commit’s data (via its corresponding snapshot), and then subsequently delete locks to ‘release’ access.
Motivation
MMS5 Flexo MMS is designed to be a multi-tenant graph database for model management with version control history. To provide clients with random access to a model’s commit history and optimally perform arbitrary read-only queries against it, a system would have to build a complete snapshot for each state in that model’s commit history. However, large projects with frequent commits pose a resource challenge. Storing a complete copy of a project’s model for each commit can quickly impact query performance or even exhaust the storage capacity of the underlying triplestore.
Instead, MMS5 Flexo MMS automatically builds and deletes snapshots according to a project’s set of refs. In this context, ‘refs’ include branches, such as master, develop, etc., so that the latest commit for any branch always has a corresponding snapshot. This approach defers decisions to the user about which other commits should have snapshots, i.e., users indicate which commits they want to be able to query by creating locks.
...
In the example below, Lock [app1:8fdd1] immutably points to Commit #8fdd1 and materializes a snapshot of the model at that state. In this case, the lock is held by some application ‘app1’. As long as this lock exists, so shall the snapshot. Once the lock is deleted, MMS5 Flexo MMS is free to evict the snapshot from the database.
Commit #9822e and Commit #2c01c share the same parent Commit #73ab9 . This divergence in the chain manifests different states of the model, captured by the Branch [master] and Branch [develop] refs (each of which materializes a snapshot). Notice that Branch [master] and Lock app2:9822e point to the same commit and share the same snapshot. From the user’s perspective, the allocation of snapshots is opaque, but it is shown here to demonstrate that MMS5 Flexo MMS conserves resources when possible.
...
| Code Block | ||
|---|---|---|
| ||
Application A creates the lock "app-a:e4a1c" on commit #e4a1c Flexo MMS5MMS builds a snapshot for commit #e4a1c Application B creates the lock "app-b:e4a1c" on commit #e4a1c Application A queries the virtual endpoint for "app-a:e4a1c" Application A deletes the lock "app-a:e4a1c" to release commit #e4a1c Application B queries the virtual endpoint for "app-b:e4a1c" Application B deletes the lock "app-b:e4a1c" to release commit #e4a1c MMS5Flexo MMS drops the snapshot for commit #e4a1c |
...
Since this process necessarily destroys the original snapshot of the parent commit, conflicting updates from other clients would cause a sudden need to rebuild the destroyed snapshot. Instead, MMS5 Flexo MMS mitigates these potential concurrency issues by maintaining an identical copy of each snapshot’s model graph in a “staging graph” that is dedicated to performing updates for new commits. This technique provides some buffer around a rapidly changing branch, allowing concurrent reads to succeed against the parent commit while also reducing latency for concurrent, conflicting updates.
...