...
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 is conserves resources when possible.
...
Branches
A branch is simply a type ref that MMS5 gets automatically adjusts adjusted to point at the latest commit upon successful updates. As long as a branch exists, it will always have a snapshot materialized in the triplestore database ready to be queried and updated.
...
The lock-for-snapshot paradigm means that applications can create namespaced locks in order to ‘lock’ access to a particular commit, without interfering with other applications. The pseudoexample below demonstrates what this concept looks like in practice with two separate applications acquiring locks on the same commit:
| Code Block | ||
|---|---|---|
| ||
Application A creates the lock "app-a:e4a1c" on commit #e4a1c MMS5 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 MMS5 drops the snapshot for commit #e4a1c |
...
Before the server can submit a SPARQL Update to the triplestore quadstore in order to create a new commit, it must ensure that the parent commit is materialized as a snapshot in a named graph. This snapshot is needed since the SPARQL Update mutates the contents of the dataset it is applied against. Once the update has been applied, the resulting dataset will represent a snapshot of the new commit.
...