Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

1.2. Effective staging graph

check back soon..First, see https://openmbee.atlassian.net/wiki/spaces/OPENMBEE/pages/613613569/Tags+and+Snapshots#Staging-graphs for an explanation of staging graphs.

An ‘effective’ staging graph simply refers to a graph that is used to apply an update, whether or not it was previously dedicated to being a staging graph.

Normally, if a staging graph is available for the parent commit, then this graph is selected to be the effective staging graph for the update and the algorithm continues to 1.3 .

However, it is possible that a staging graph for the latest commit is not yet available. This can happen when multiple updates are made to the same branch concurrently and the triplestore has not yet had enough time to COPY the snapshot graph to a dedicated staging graph. In this scenario, MMS5 uses the snapshot graph as an effective staging graph. This technique ultimately defers the COPY operation to a later time once any concurrent writes have settled.

For example, in the following diagram, e4a1c represents the latest commit at state #01 of the model. Notice how a snapshot graph and a staging graph materialize this same commit:

Code Block
#01:

 *snapshot -╮
            ├- *staging
            ╎
    (x)---e4a1c

Upon an update, a new commit 17ccd is created by using the staging graph to evolve the state of the model to #02:

Code Block
#02:

 *snapshot -╮
            ╎       ╭*ephemeral-snapshot-1
            ╎       ╎
    (x)---e4a1c---17ccd

At this point, 17ccd does not yet have its own staging graph. Since it is brand new, it’s snapshot graph is marked as “ephemeral”, which means that (a) it does not yet have a staging graph and (b) it’s (super*)parent still has a snapshot being used for interim reads and updates. Before a staging graph for this new commit is built, MMS5 finishes processing any remaining concurrent updates. In this example, one such update creates a new commit 8f155. The server uses the aforementioned ephemeral snapshot graph as the effective staging graph to apply this update. The new state of the model at #03 looks like:

Code Block
#03:

 *snapshot -╮
            ╎               ╭*ephemeral-snapshot-2
            ╎               ╎
    (x)---e4a1c---17ccd---8f155

Once the pipeline of concurrent writes have ceased, MMS5 is able to stabilize the latest commit’s snapshot at #04:

Code Block
#04:

 *snapshot -╮    *snapshot -╮
            ╎               ├- *staging
            ╎               ╎
    (x)---e4a1c---17ccd---8f155

Finally, the now expired snapshot for the original commit is dropped and MMS5 settles on the resting state for this model at #05:

Code Block
#05:

                 *snapshot -╮
                            ├- *staging
                            ╎
    (x)---e4a1c---17ccd---8f155