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

Make the BigdataSail UNISOLATED connection global in scope.

    Details

      Description

      BigdataSail#getUnisolatedConnection() uses a semaphore to impose the restriction that there can be at most one writer with the UNISOLATED connection at a given time. However, the semaphore is scoped by the BigdataSail instance and is thus unable to protect against applications which wrap the UNISOLATED view of a triple store instance more than once. Further, for ACID semantics in the standalone database, there should really only be a single UNISOLATED connection regardless of which triple store instance is address. E.g., if you have two different triple stores in the same database, the UNISOLATED connection should be restricted such that only one thread for one of those stores can hold that connection at a time. As it stands, it is possible for one thread to be granted that connection for each of those distinct triple store instances. However, doing so weakens the ACID semantics of an operation on the UNISOLATED connection since a commit invoked against one triple store could cause writes to be flushed through and incorporated into a commit point for another triple store.

      This issue exists in the trunk and in the quads branch. It should be fixed in both.

        Activity

        Hide
        bryanthompson bryanthompson added a comment -

        This change has been ported to the trunk as of r4454.

        Show
        bryanthompson bryanthompson added a comment - This change has been ported to the trunk as of r4454.
        Hide
        bryanthompson bryanthompson added a comment -

        A Semaphore has been added to the Journal for this purpose and two methods have been exposed to acquire and release that Semaphore. The Semaphore is provisioned with one initial permit and attempts to enforce a mutex constraint. The BigdataSail was modified to acquire this permit when obtaining an unisolated connection and to release the permit when the connection is closed.

        Several unit tests were updated to verify correct behavior of getUnisolatedConnection().

        Several openrdf unit tests which were silently being ignored due to an incompatible semantics for transaction isolation were modified to reflect the snapshot isolation of bigdata read/write transactions (versus the read-committed isolation of openrdf transactions).

        The contributed unit test TestRollbacks was committed. See https://sourceforge.net/apps/trac/bigdata/ticket/278#comment:8.

        These changes are currently against the QUADS_QUERY_BRANCH and need to be ported to the trunk before we can close this issue.

        Committed revision r4449.

        Show
        bryanthompson bryanthompson added a comment - A Semaphore has been added to the Journal for this purpose and two methods have been exposed to acquire and release that Semaphore. The Semaphore is provisioned with one initial permit and attempts to enforce a mutex constraint. The BigdataSail was modified to acquire this permit when obtaining an unisolated connection and to release the permit when the connection is closed. Several unit tests were updated to verify correct behavior of getUnisolatedConnection(). Several openrdf unit tests which were silently being ignored due to an incompatible semantics for transaction isolation were modified to reflect the snapshot isolation of bigdata read/write transactions (versus the read-committed isolation of openrdf transactions). The contributed unit test TestRollbacks was committed. See https://sourceforge.net/apps/trac/bigdata/ticket/278#comment:8 . These changes are currently against the QUADS_QUERY_BRANCH and need to be ported to the trunk before we can close this issue. Committed revision r4449.
        Hide
        bryanthompson bryanthompson added a comment -

        I'm trying to close the hole in BigdataSail#getUnisolatedConnection() right now. I really need to work up a test case which demonstrates a problem so I can validate the fix. I think that we have the angle on how the problem might have crept [1] in due to the lack of appropriate synchronization on (Abstract|Local)TripleStore#abort() IF it is also possible for them to have two distinct UNISOLATED connections since those actions would have otherwise been synchronized at BigdataSailConnection#rollback() or commit(). However, the only way I can think of to get around the ReentrantReadWriteLock used by the BigdataSail to enforce a single UNISOLATED connection is by wrapping the sail more than once around the same Journal. Each such BigdataSail instance would be distinct and hence have a distinct ReentrantReadWriteLock and hence not guarantee a single UNISOLATED connection.

        [1] https://sourceforge.net/apps/trac/bigdata/ticket/288#comment:6

        Show
        bryanthompson bryanthompson added a comment - I'm trying to close the hole in BigdataSail#getUnisolatedConnection() right now. I really need to work up a test case which demonstrates a problem so I can validate the fix. I think that we have the angle on how the problem might have crept [1] in due to the lack of appropriate synchronization on (Abstract|Local)TripleStore#abort() IF it is also possible for them to have two distinct UNISOLATED connections since those actions would have otherwise been synchronized at BigdataSailConnection#rollback() or commit(). However, the only way I can think of to get around the ReentrantReadWriteLock used by the BigdataSail to enforce a single UNISOLATED connection is by wrapping the sail more than once around the same Journal. Each such BigdataSail instance would be distinct and hence have a distinct ReentrantReadWriteLock and hence not guarantee a single UNISOLATED connection. [1] https://sourceforge.net/apps/trac/bigdata/ticket/288#comment:6

          People

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

            Dates

            • Created:
              Updated:
              Resolved: