Concurrent Integrity Constraint Validation

[eltons (Elton Figueiredo de Souza Soares)]

Hi, I'm facing an issue in a project where we need to guarantee that concurrent modifications of the same instances will not cause the database to be inconsistent.

In our current implementation we are have a single triple store (AllegroGraph) which is used for storing the application data. The storage is performed through a database service, which receives requests from a web application.

The problem is, that our database service must be replicated (through containers), in order to allow our system to scale according to the number of requests received. This replication, opens the possibility that two requests which are being processed through distinct replicas of this service could cause inconsistent modifications in the database, which is not replicated.

Stargod's Integrity Constraint Validation (ICV) guard mode could be a solution to oproblem, but reading the documentation, it was not clear whether the ICV guard mode guarantees that concurrent transaction commits would be validated against each other.

In Home | Stardog Documentation Latest it is said:
"When guard mode for ICV is enabled in Stardog, each commit is inspected to ensure that the contents of the database are valid for the set of constraints that have been associated with it. Should someone attempt to commit data which violates one or more of the constraints defined for the database, the commit will fail and the data will not be added/removed from your database."

Lets say that we have two transactions that individually do not inflict the database constraints, but if made at the same time would cause a conflict. How does Stardog handles that?

Thank for you support!

[stephen]

Hi,

ICV guard mode will disallow the commit of whichever of the two transactions is last. It will not allow you to have bad data loaded.

[hmottestad]

We have run into ICV allowing invalid data to be loaded when using SNAPSHOT_ISOLATION. This can only happen once though, and any subsequent inserts were not allowed until the offending triples were removed.

Our ICV rules take quite a long time to complete, so we have written synchronisation code in our java api layer to stop this sort of issue from cropping up.

For us it was max count constraints that didn’t work as expected. Two transactions that start at the same time (with the same snapshot) can both insert triples that are separately valid for the max count constraint, but together they are invalid. ICV does not detect this until after both transactions have committed and you attempt to commit a third transaction later.

If you enable SERIALIZABLE as the isolation level in stardog, then ICV will work exactly as expected.