...
Unfortunately, the SPARQL 1.1 Protocol does not standardize any type of response content to a SPARQL Update request. Some triplestores will provide detailed information about how many triples were affected by an update, while others simply indicate whether the request succeeded or failed as an atomic unit by using HTTP status codes. For these reasons, the server must first test the UPDATE_CONDITION using an ASK query before issuing an update operation. The ASK query returns a boolean to indicate whether the given WHERE block matches the specified dataset(s). Fortunately, the server can issue multiple ASK queries in parallel, allowing the triplestore to handle load-balancing the queries against separate graphs and reduce the total time spent waiting for query results to determine which commit will be used to apply the update. Depending on several factors, using the read-only ASK operation to search multiple graphs in parallel to find those which satisfy the UPDATE_CONDITION might even outperform the aforementioned update-until-it-works technique, though this is only speculationIf zero graphs match the update condition, the request is deemed unsatisfiable and an appropriate HTTP error code is returned to the client. If multiple graphs match the update condition, the one corresponding to the most recent commit is selected. The result is that merge conflicts are automatically detected by employing the update condition to assess whether an update’s dependencies are satisfied on any given state of a model.
1.2. Effective staging graph
...
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. See https://openmbee.atlassian.net/wiki/spaces/OPENMBEE/pages/616497153/Layer+1+Update+Procedure#Effective-staging-graph-example below for an example of using an ephemeral snapshot as an effective staging graph.
1.3. SPARQL update execution
Having selected an effective staging graph to apply the model update to, MMS5 then executes a SPARQL update against the triplestore that performs several operations at a single atomic unit. They are summarized as:
acquire an exclusive write lock to the effective staging graph
detach the effective staging graph from its current owner
create a new ephemeral commit object in the project’s metadata graph
apply the model update to the effective staging graph
attach the effective staging graph to the new ephemeral commit
release the write lock
1.4. Commit stabilization
Following a series of 1 or more successive writes to a branch, the server must stabilize commit data by creating new staging graphs and dropping old snapshots that are no longer needed. Delaying this action by some predetermined amount of time will improve the performance of any queries or updates that target or depend on the parent commit.
Effective staging graph example
For example, in 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:
...