Transaction support

[Leif Warner <ab...@gmail.com>]

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 commit, only on abort.

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?

-Leif Warner
[1] http://tools.ietf.org/html/rfc5789
[2] http://vocab.org/changeset/schema.html
[3] http://www.callimachusproject.org/

Re: Transaction support

[Dave Reynolds <da...@gmail.com>]

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