On 20/08/2011 23:04, Leif Warner wrote:
I'd like to have an endpoint that responds to the HTTP PATCH method
[1], that is, for someone to be able to send a PATCH whose body is
along the lines of the Talis changeset ontology [2], lists of triples
to be removed and added.
It's probably best for that modification to be atomic, ie in a
transaction. I notice on the com.hp.hpl.jena.rdf.model.Model
interface transaction operations like begin, commit, and abort. But
supportsTransactions returns false when I tried the default in-memory
model, TDB, and tx-TDB. At least tx-TDB didn't throw "unsupported"
exceptions when I tried begin and commi, only on abort.
tx-TDB has a special API for handling transactions (which I think is
still being finalized). It can't just use the primitive Jena
being/commit/abort because it needs to know about readers as well as
writers.
Guess I was wondering how supported are these kind of things, or if
anyone has any advice? I know I could use a SPARQL endpoint, and apps
like Callimachus [3] have the browser send back changesets in the form
of a SPARQL Update query, but my server app at present is doing a lot
of simple model.listStatements graph traversals, and having the client
know how to construct SPARQL Update queries seems like overkill.
At present, would the simplest thing on a smallish-in memory store be
to set a global lock when doing modifications, and to wrap calls to
"listStatements" with an API that checks for the lock and queues
requests in the meantime?
Exactly, for Memory and TDB then they can only be used from a single JVM
anyway and there is no selective locking- so the standard pattern is to
wrap Model.enterCriticalSection/leaveCriticalSection round all sets of
read/write accesses.
You may want to look at Fuseki which supports SPARQL 1.1 update which
allows a richer range of operations that the Talis changesets.
SDB, of course, can use the transactionality of the underlying database.
Dave
