[COMMONSRDF-45] Support longer-running RDF4J transactions?

• Type: Wish
• Status: Open
• Priority: Major
• Resolution: Unresolved
• Affects Version/s: 0.3.0
• Component/s: rdf4j
• Assignee: Unassigned
• Reporter: Stian Soiland-Reyes
• Created: 09/Oct/16 01:09
• Updated: 27/Oct/16 09:04

Description

RDF4J operations like Graph.add() uses an internal RepositoryConnection that is closed on every method call.

This could cause a performance hit.

This task is to investigate how big that hit is for different backends, and to propose an alternative to support more longer-running transactions.

For instance, one alternative would be:

{code:
Dataset g = rdf4j.createDataset();

try (TransactionalDataset t = g.begin()) {
t.add(triple1);
t.add(triple2);
t.remove(triple3);

t.commit();
// or
// t.abort()
}

where TransactionalDataset is subtype of Dataset with a shared connection. Here modifications in t won't be visible in g before the commit - but I guess we could expose some of the different transaction isolation levels from RDF4J.

This could call abort() if an exception is thrown. Perhaps .commit() would be the default if everything is OK and so not needed explicitly - but that could cause unnecessary "empty commits" for read-only transactions (e.g. using .contains() or .iterate())

Issue Links

• is related to: COMMONSRDF-4 Transaction Model