Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Transaction capability appears to disagree with documentation #230

Open
danjhugo opened this issue Jun 2, 2022 · 0 comments
Open

Transaction capability appears to disagree with documentation #230

danjhugo opened this issue Jun 2, 2022 · 0 comments

Comments

@danjhugo
Copy link

danjhugo commented Jun 2, 2022

At https://github.com/blazegraph/database/wiki/REST_API#transaction-management-api, we have the note: "Either the txId or the readsOnCommitTime may be used for the &timestamp=... parameter on the REST API methods." However, this appears to be only partly true (I'm running 2.1.6)...

  1. Doing a SPARQL select query (through the REST API) with HTTP query parameter &timestamp=(the value given by readsOnCommitTime of transaction response) does give data as expected for that time (i.e. you don't see any data that was inserted after that time).

  2. Doing a select query through the REST API with &timestamp=(txId of a RW transaction) doesn't work; it still returns data newer than that transaction's creation time. I suspect this has something to do with the txId provided being a negative integer.

  3. Similarly, if I perform a SPARQL update to insert data through the REST API with &timestamp set to either the txId or readsOnCommitTime, that data is available immediately for a non-transactional SPARQL select query (before the transaction has been either aborted or committed). If I abort the transaction, the data remains committed.

In UpdateServlet.java, I can see references to readOnlyTimestamp and ITx.UNISOLATED... I can't see an indication that it's actually attempting to do isolated operations in a read-write transaction.

So, it looks to me as if either the (a) documentation is advertising a capability that is not actually available yet (meaning the documentation should be revised to indicate this), or (b) there's some implementation detail that is preventing RW transactions from behaving as expected (though I can't see where/what this would be).

Has functionality for performing updates inside a read-write transaction actually been implemented yet?

Or am I just using the API incorrectly? To put it another way, when the documentation says "POST /bigdata/tx => txId \n doWork(txId).... \n POST /bigdata/tx/txid?COMMIT", what is the "doWork(txId)" bit supposed to look like for sparql updates?

Any information would be appreciated! :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants
@danjhugo and others