Uploaded image for project: 'Blazegraph (by SYSTAP)'
  1. Blazegraph (by SYSTAP)
  2. BLZG-2041

BigdataSail should not locate the AbstractTripleStore until a connection is requested

    XMLWordPrintable

    Details

      Description

      See BLZG-2023. One of the underlying issues is that we are locating the unisolated view of the AbstractTripleStore in the BigdataSail constructor rather than waiting until we obtain an unisolated connection. This forces some of the lock handling logic onto the caller and is the root cause of BLZG-2023. We do have a fix for BLZG-2023, but it pushes more responsibility onto the caller. This ticket is to explore an alternative which encapsulates that complexity in BigdataSail by deferring the resolution of the AbstractTripleStore.

      We are exploring pushing down the locate of the unisolated view of the AbstractTripleStore into BigdataSail.getXXXConnection(). For the unisolated connection (getUnisolatedConnection()), this would defer the locate until we have the semaphore and clean up the external lock coordination. Doing this would mean removing the following fields and access methods from BigdataSail and BigdataSailRepository, pushing them down onto BigdataSailConnection and BigdataSailRepositoryConnection.

      Remove:

      • BigdataSail.AbstractTripleStore:database, getDatabase() / getAbstractTripleStore()
      • BigdataSail.getInferenceEngine() (this one is easy since it is only used by BigdataSailConnection anyway).

      Add:

      • BigdataSail.getIndexManager()
      • BigdataSail.getNamespace()
      • BigdataSail.indexManager:IIndexManager
      • BigdataSail.namespace:String (the namespace name)

      Problems:

      • BigdataSail.getValueFactory() defers to the LexiconRelation constructor, which allows override of the ValueFactory implementation class. Could probably be replaced by just "valueFactory = BigdataValueFactoryImpl.getInstance(namespace);" which could be directly implemented by BigdataSail.
      • BigdataSail.getWritable() - this would need to be changed to indicate whether or not the BigdataSail was willing to allow the caller to obtain a writable connection. I think that we always allow this, so it might just return "true".

      We are working through the implications of these changes. BigdataSail.getDatabase() is used quite broadly. As long as we have a BigdataSailConnection object, we can simply access the AbstractTripleStore on that connection. However, if we have only the BigdataSail then we might need to modify the caller to explicitly obtain, use, and release a BigdataSailConnection for the operation. In most circumstances, the unisolated connection or a read-only connection on the lastCommitTime would be the most appropriate connection objects to obtain.

      Note: One possible consequence of this ticket would be slightly more overhead when obtaining a connection from the BigdataSail.

      Note: This change set would likely conflict with BLZG-420. We might have to redo BLZG-420 against the current master, which might be a good idea anyway.

      Brad Bebee
      martyncutcher
      michaelschmidt

        Attachments

          Issue Links

          There are no Sub-Tasks for this issue.

            Activity

              People

              Assignee:
              bryanthompson bryanthompson
              Reporter:
              bryanthompson bryanthompson
              Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: