Deletion of triples in different transaction in MarkLogic

Question

I am using MarkLogic 8

I have to delete triples using sem:sparql-update in the first statement and don't want to get the same deleted triples in the next statement using sem:sparql.

I tried passing sem:sparql-update in xdmp:invoke-function but it's not working.

In sem:sparql-update it is said that the default isolation will be 'different-transaction', If that is the case I believe I should not be getting the deleted triples in the immediate statement of sem:sparql-update.

Please help!

Answer 1

You need to run both sem:sparql-update and sem:sparql in different-transactions. sem:sparql would otherwise run with the timestamp of the request which invokes the update, which pre-dates the updates themselves, so it would never be able to see the updates.

It is part of the MVCC methodology that MarkLogic uses for its transaction handling.

HTH!

Answer 2

I highly recommend reading the Understanding Transactions in MarkLogic Server chapter of the Application Developer's Guide.

Statements in MarkLogic are either requests or updates. Requests happen at a particular timestamp and are read-only, which means that what they see is stable. Because of this, requests don't have to worry about write locks. Updates make changes to the database. For XQuery, MarkLogic knows which you're doing by way of static analysis (for JavaScript, you have to call declareUpdate()). If you're not sure which you're running, you can call xdmp:request-timestamp; a request will give you a value, but an update will give you the empty sequence.

You want to do an update and have those changes be visible to a later SPARQL query. There are two possible ways, depending on whether the parent request is a query or an update.

In either case, you're on the right track that your sem:sparql-update call needs to be in a different transaction.

Parent is an update

If the parent request is an update, then a request made after the separate-transaction sparql-update will be visible. You won't need to do anything special except to make sure your read comes after the sparql-update.

Parent is a query

If the parent request is query, then it's running at a set timestamp and won't see the results of the sparql-update. In this case, you'd want to also run the sem:sparql as a separate transaction, which will allow it to see the results of the already-completed update transaction.

Note that if the parent is a query, it would technically work to make it an update, but that's unlikely to be a good plan. In that case, the entire parent request would have more locks to worry about.