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

Support longer-running RDF4J transactions?

    XMLWordPrintableJSON

Details

    • Wish
    • Status: Open
    • Major
    • Resolution: Unresolved
    • 0.3.0
    • None
    • rdf4j
    • 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

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

              Dates

                Created:
                Updated: