Details

      Description

      I've been working on a partial fix to JCR-630. Instead of implementing fully transactional versioning (i.e. a checkin will disappear when a transactin is rolled back), I'm ensuring that all versioning operations within a transaction will leave the version store in a consistent state even if the transaction otherwise fails at any point.

        Issue Links

          Activity

          Hide
          Jukka Zitting added a comment -

          The XA case should also be fixed as of revision 710047. The sequence of saves for a checkin/checkout operation within an XA transaction is now:

          VERSION_:

          {#addedStates=14, #modifiedStates=3, #deletedStates=0, #modifiedRefs=0}

          DEFAULT_:

          {#addedStates=0, #modifiedStates=3, #deletedStates=0, #modifiedRefs=0}

          VERSION_:

          {#addedStates=0, #modifiedStates=0, #deletedStates=0, #modifiedRefs=1}

          All tests (including a massive random/parallel test suite I ran over the weekend) pass.

          Show
          Jukka Zitting added a comment - The XA case should also be fixed as of revision 710047. The sequence of saves for a checkin/checkout operation within an XA transaction is now: VERSION_: {#addedStates=14, #modifiedStates=3, #deletedStates=0, #modifiedRefs=0} DEFAULT_: {#addedStates=0, #modifiedStates=3, #deletedStates=0, #modifiedRefs=0} VERSION_: {#addedStates=0, #modifiedStates=0, #deletedStates=0, #modifiedRefs=1} All tests (including a massive random/parallel test suite I ran over the weekend) pass.
          Hide
          Jukka Zitting added a comment -

          The behaviour without transactions is as expected, even though it results in more store operations than would be optimal. The XA case is wrong, and I've been trying to address that.

          First I revisited my original plan of solving both the transaction issue and optimize the number of stores in versioning operations by moving the NodeReferences that point to the version store to the workspace persistence managers. This would improve a number of things but breaks the backreference checks for example when deleting versions. I had an idea to resolve that issue but unfortunately it didn't work out too well in practice.

          As a fallback I'm now solving just the XA case and leaving the multiple store operations in place.

          Show
          Jukka Zitting added a comment - The behaviour without transactions is as expected, even though it results in more store operations than would be optimal. The XA case is wrong, and I've been trying to address that. First I revisited my original plan of solving both the transaction issue and optimize the number of stores in versioning operations by moving the NodeReferences that point to the version store to the workspace persistence managers. This would improve a number of things but breaks the backreference checks for example when deleting versions. I had an idea to resolve that issue but unfortunately it didn't work out too well in practice. As a fallback I'm now solving just the XA case and leaving the multiple store operations in place.
          Hide
          Przemo Pakulski added a comment -

          D1V1R2 - is name of the workspace, VERSION is schemaObjectPrefix, i'm using MSSqlPersistenceManager

          Show
          Przemo Pakulski added a comment - D1V1R2 - is name of the workspace, VERSION is schemaObjectPrefix, i'm using MSSqlPersistenceManager
          Hide
          Przemo Pakulski added a comment - - edited

          I've created custom PM by simply overriding one method, to be able to track the sequence of stored changes :

          public synchronized void store(ChangeLog changeLog) throws ItemStateException

          { super.store(changeLog); log.warn("STORE :" + getSchemaObjectPrefix() + ": " + changeLog); }

          Then I run checkout/checkin operation on single node :

          1) without transaction

          checkout

          11:12:17 WARN STORE :D1V1R2_:

          {#addedStates=0, #modifiedStates=2, #deletedStates=0, #modifiedRefs=0}

          11:12:17 WARN STORE :VERSION_:

          {#addedStates=0, #modifiedStates=0, #deletedStates=0, #modifiedRefs=1}

          checkin

          11:12:17 WARN STORE :VERSION_: {#addedStates=13, #modifiedStates=3, #deletedStates=0, #modifiedRefs=0}
          11:12:17 WARN STORE :D1V1R2_: {#addedStates=0, #modifiedStates=3, #deletedStates=0, #modifiedRefs=0}
          11:12:17 WARN STORE :VERSION_: {#addedStates=0, #modifiedStates=0, #deletedStates=0, #modifiedRefs=1}

          11:12:17 WARN STORE :VERSION_:

          {#addedStates=0, #modifiedStates=0, #deletedStates=0, #modifiedRefs=1}

          2) checkout/checkin in transaction

          11:13:57 WARN STORE :D1V1R2_: {#addedStates=0, #modifiedStates=3, #deletedStates=0, #modifiedRefs=0}
          11:13:57 WARN STORE :VERSION_: {#addedStates=0, #modifiedStates=0, #deletedStates=0, #modifiedRefs=1}

          11:13:57 WARN STORE :VERSION_:

          {#addedStates=13, #modifiedStates=3, #deletedStates=0, #modifiedRefs=1}

          Checkout/checkin in single JCR transaction still consist of 3 database level transactions,

          Moreover when using transactions, as you can see from the logs changes in workspace are persisted first before storing changes in the version storage.

          This is probably because of order of txResources in XASessionImpl class as described in JCR-631.

          Show
          Przemo Pakulski added a comment - - edited I've created custom PM by simply overriding one method, to be able to track the sequence of stored changes : public synchronized void store(ChangeLog changeLog) throws ItemStateException { super.store(changeLog); log.warn("STORE :" + getSchemaObjectPrefix() + ": " + changeLog); } Then I run checkout/checkin operation on single node : 1) without transaction checkout 11:12:17 WARN STORE :D1V1R2_: {#addedStates=0, #modifiedStates=2, #deletedStates=0, #modifiedRefs=0} 11:12:17 WARN STORE :VERSION_: {#addedStates=0, #modifiedStates=0, #deletedStates=0, #modifiedRefs=1} checkin 11:12:17 WARN STORE :VERSION_: {#addedStates=13, #modifiedStates=3, #deletedStates=0, #modifiedRefs=0} 11:12:17 WARN STORE :D1V1R2_: {#addedStates=0, #modifiedStates=3, #deletedStates=0, #modifiedRefs=0} 11:12:17 WARN STORE :VERSION_: {#addedStates=0, #modifiedStates=0, #deletedStates=0, #modifiedRefs=1} 11:12:17 WARN STORE :VERSION_: {#addedStates=0, #modifiedStates=0, #deletedStates=0, #modifiedRefs=1} 2) checkout/checkin in transaction 11:13:57 WARN STORE :D1V1R2_: {#addedStates=0, #modifiedStates=3, #deletedStates=0, #modifiedRefs=0} 11:13:57 WARN STORE :VERSION_: {#addedStates=0, #modifiedStates=0, #deletedStates=0, #modifiedRefs=1} 11:13:57 WARN STORE :VERSION_: {#addedStates=13, #modifiedStates=3, #deletedStates=0, #modifiedRefs=1} Checkout/checkin in single JCR transaction still consist of 3 database level transactions, Moreover when using transactions, as you can see from the logs changes in workspace are persisted first before storing changes in the version storage. This is probably because of order of txResources in XASessionImpl class as described in JCR-631 .
          Hide
          Jukka Zitting added a comment -

          Fixed in trunk. I have streamlined a number of the versioning operations and made sure that all versioning changes are persisted strictly before they get referenced in normal workspace content.

          Show
          Jukka Zitting added a comment - Fixed in trunk. I have streamlined a number of the versioning operations and made sure that all versioning changes are persisted strictly before they get referenced in normal workspace content.

            People

            • Assignee:
              Jukka Zitting
              Reporter:
              Jukka Zitting
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development