Uploaded image for project: 'Apache Commons RDF'
  1. Apache Commons RDF
  2. COMMONSRDF-45

Support longer-running RDF4J transactions?

    XMLWordPrintableJSON

    Details

    • Type: Wish
    • Status: Open
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: 0.3.0
    • Fix Version/s: None
    • Component/s: rdf4j
    • Labels:
      None

      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())

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                Unassigned
                Reporter:
                stain Stian Soiland-Reyes
              • Votes:
                0 Vote for this issue
                Watchers:
                1 Start watching this issue

                Dates

                • Created:
                  Updated: