ModeShape
  1. ModeShape
  2. MODE-1289

JCR layer should use Infinispan for caching and storage

    Details

    • Affects:
      Compatibility/Configuration
    • Estimated Difficulty:
      High
    • Similar Issues:
      Show 10 results 

      Description

      ModeShape's JCR layer should have a much more integrated and universal caching layer, and should use Infinispan for this. And because Infinispan's cache loaders are capable of persisting the cached information, we can have Infinispan actually store the content. The cached information should be a JSON-like document structure that is easily serialized (e.g., to JSON and/or BSON), and we can use a single document for each node. This approach would allowing us to store not only the properties and child references, but additional information not normally exposed through JCR. (The old graph API was not able to do this, and this required too much specific handling to hide certain graph properties.)

      This new approach was described in more detail in the referenced community forum post.

        Issue Links

          Activity

          Hide
          Randall Hauch
          added a comment - - edited

          Added a fifth pull-request, with the following changes.

          Prior to this change (and in 2.x), the RepositoryNodeTypeManager used a read/write lock around the cache of node type information. This not only slowed things down, but having a shared cache allowed the state to change while in the middle of an operation.

          This commit changes the RepositoryNodeTypeManager to keep an internal but immutable cache of the node type information. This cache is easily accessible to the rest of the package components, and because it's immutable there is no need for any internal locking within the cache. Every time node types are registered or unregistered, the cache is rebuilt in an atomic fashion (still within a write-lock within the RepositoryNodeTypeManager) and the old cache replaced.

          Many of the Node and Property implementation methods that use the node type manager were changed to get the node type cache once and use it for the rest of the method.

          The performance improvements might be minimal, but this should increase the consistency of various operations (e.g., Node.addMixin, Property.getPropertyDefinition(), etc.) even when the node types are being changed.

          Added more tests for mixins and some JCR iterator implementations.

          All tests pass with these changes.

          Show
          Randall Hauch
          added a comment - - edited Added a fifth pull-request , with the following changes. Prior to this change (and in 2.x), the RepositoryNodeTypeManager used a read/write lock around the cache of node type information. This not only slowed things down, but having a shared cache allowed the state to change while in the middle of an operation. This commit changes the RepositoryNodeTypeManager to keep an internal but immutable cache of the node type information. This cache is easily accessible to the rest of the package components, and because it's immutable there is no need for any internal locking within the cache. Every time node types are registered or unregistered, the cache is rebuilt in an atomic fashion (still within a write-lock within the RepositoryNodeTypeManager) and the old cache replaced. Many of the Node and Property implementation methods that use the node type manager were changed to get the node type cache once and use it for the rest of the method. The performance improvements might be minimal, but this should increase the consistency of various operations (e.g., Node.addMixin, Property.getPropertyDefinition(), etc.) even when the node types are being changed. Added more tests for mixins and some JCR iterator implementations. All tests pass with these changes.
          Hide
          Randall Hauch
          added a comment -

          Merged the fifth pull-request into the '3.x' branch.

          Show
          Randall Hauch
          added a comment - Merged the fifth pull-request into the '3.x' branch.
          Hide
          Randall Hauch
          added a comment -

          Added another pull-request.

          Although RepositoryCache uses transactions for its changes to Infinispan content, it still is possible for one session to make changes to a node and, before that session is saved, another session removes the node and persists its changes. In this case, when the first session attempts to save its changes (e.g., modifying a now-removed node) the save operation needs to throw an InvalidItemStateException. At this point, the session's owner can either abort all the changes or try to recover.

          All unit and integration tests pass with these changes.

          Show
          Randall Hauch
          added a comment - Added another pull-request . Although RepositoryCache uses transactions for its changes to Infinispan content, it still is possible for one session to make changes to a node and, before that session is saved, another session removes the node and persists its changes. In this case, when the first session attempts to save its changes (e.g., modifying a now-removed node) the save operation needs to throw an InvalidItemStateException. At this point, the session's owner can either abort all the changes or try to recover. All unit and integration tests pass with these changes.
          Hide
          Randall Hauch
          added a comment -

          Merged the pull-request into the '3.x' branch.

          Show
          Randall Hauch
          added a comment - Merged the pull-request into the '3.x' branch.
          Hide
          Randall Hauch
          added a comment -

          Marking as resolved, since most of this work has been completed. Outstanding items or problems will be handled as separate issues.

          Show
          Randall Hauch
          added a comment - Marking as resolved, since most of this work has been completed. Outstanding items or problems will be handled as separate issues.

            People

            • Assignee:
              Randall Hauch
              Reporter:
              Randall Hauch
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: