Uploaded image for project: 'Jackrabbit Oak'
  1. Jackrabbit Oak
  2. OAK-14

Identify and document changes in behaviour wrt. Jackrabbit 2

    Details

      Description

      Some implementation specific behaviour will likely change. We should document the cases, provide test cases and migration paths where applicable.

      This issue serves as a container. Please create separate issues for each identifies change in behaviour.

        Issue Links

          Activity

          Hide
          mduerig Michael Dürig added a comment -

          Here is a list of things we need to keep an eye on. The list is compiled from the experience I made within the experimental implementations in the sandbox [1, 2]. We should make them into separate issues as we encounter them in our implementation effort.

          • SNS: Implement through name mangling. Raise a JSR issue if necessary.
          • Query and eventual consistency: would it be tolerable to have the query index not up to date yet? (i.e. after a possibly large save.) This could either result in incomplete query results, an exception or the query to be deferred until the index is up to date. Maybe we could even let the client chose through 'query hints'.
          • refresh/save/revert wrt. MVCC: Both refresh and save will bring the session up to the current head revision. There is thus no revert semantics in the API. Since we are closer to the SVN use case now where conflicts are resolved on the client it might be necessary to introduce a Item.revert, Session.revert. See http://java.net/jira/browse/JSR_333-47
          • MVCC wrt. Item.refresh, Item.save: Are troublesome since then revisions need to be tracked per item instead of per session. Later commits would have to be made atomic across various revisions instead of only a single one.
          • MVCC wrt. observation: Semantics change somewhat since a session might receive events "from the future". That is, events from a newer revision than the current session's. Trying to get a node from an NODE_ADDED event might thus result in an ItemNotFoundException unless the session is refreshed. In contrast nodes referred to by a NODE_REMOVED events will still be visible to the session. An approach to mitigate this is to have read only sessions which are always on the newest revision (i.e. see all saved changes).
          • Node type consistency currently not fully achievable due to write skew effects exposed by snapshot isolation [3]

          [1] http://svn.apache.org/viewvc/jackrabbit/sandbox/jackrabbit-mk/
          [2] http://svn.apache.org/viewvc/jackrabbit/sandbox/jackrabbit-microkernel/
          [3] http://wiki.apache.org/jackrabbit/Transactional%20model%20of%20the%20Microkernel%20based%20Jackrabbit%20prototype

          Show
          mduerig Michael Dürig added a comment - Here is a list of things we need to keep an eye on. The list is compiled from the experience I made within the experimental implementations in the sandbox [1, 2] . We should make them into separate issues as we encounter them in our implementation effort. SNS: Implement through name mangling. Raise a JSR issue if necessary. Query and eventual consistency: would it be tolerable to have the query index not up to date yet? (i.e. after a possibly large save.) This could either result in incomplete query results, an exception or the query to be deferred until the index is up to date. Maybe we could even let the client chose through 'query hints'. refresh/save/revert wrt. MVCC: Both refresh and save will bring the session up to the current head revision. There is thus no revert semantics in the API. Since we are closer to the SVN use case now where conflicts are resolved on the client it might be necessary to introduce a Item.revert, Session.revert. See http://java.net/jira/browse/JSR_333-47 MVCC wrt. Item.refresh, Item.save: Are troublesome since then revisions need to be tracked per item instead of per session. Later commits would have to be made atomic across various revisions instead of only a single one. MVCC wrt. observation: Semantics change somewhat since a session might receive events "from the future". That is, events from a newer revision than the current session's. Trying to get a node from an NODE_ADDED event might thus result in an ItemNotFoundException unless the session is refreshed. In contrast nodes referred to by a NODE_REMOVED events will still be visible to the session. An approach to mitigate this is to have read only sessions which are always on the newest revision (i.e. see all saved changes). Node type consistency currently not fully achievable due to write skew effects exposed by snapshot isolation [3] [1] http://svn.apache.org/viewvc/jackrabbit/sandbox/jackrabbit-mk/ [2] http://svn.apache.org/viewvc/jackrabbit/sandbox/jackrabbit-microkernel/ [3] http://wiki.apache.org/jackrabbit/Transactional%20model%20of%20the%20Microkernel%20based%20Jackrabbit%20prototype
          Hide
          mreutegg Marcel Reutegger added a comment -

          > MVCC wrt. observation

          another approach that was discussed at the F2F on March 13th: automatically refresh session
          (or rather update to committed revision that caused event?) before onEvent() of observation
          listeners are called.

          Show
          mreutegg Marcel Reutegger added a comment - > MVCC wrt. observation another approach that was discussed at the F2F on March 13th: automatically refresh session (or rather update to committed revision that caused event?) before onEvent() of observation listeners are called.
          Hide
          reschke Julian Reschke added a comment -

          > MVCC wrt. observation: Semantics change somewhat since a session might receive events "from the future". That is, events from a newer revision than the current session's. Trying to get a node from an NODE_ADDED event might thus result in an ItemNotFoundException unless the session is refreshed. In contrast nodes referred to by a NODE_REMOVED events will still be visible to the session. An approach to mitigate this is to have read only sessions which are always on the newest revision (i.e. see all saved changes).

          Maybe surface the revisionid in the event, so that "smart" event listeners have more context?

          Show
          reschke Julian Reschke added a comment - > MVCC wrt. observation: Semantics change somewhat since a session might receive events "from the future". That is, events from a newer revision than the current session's. Trying to get a node from an NODE_ADDED event might thus result in an ItemNotFoundException unless the session is refreshed. In contrast nodes referred to by a NODE_REMOVED events will still be visible to the session. An approach to mitigate this is to have read only sessions which are always on the newest revision (i.e. see all saved changes). Maybe surface the revisionid in the event, so that "smart" event listeners have more context?
          Hide
          alex.parvulescu Alex Parvulescu added a comment - - edited

          Linked to SLING-2763 to refer to a potential backward compatibility issues. While it's fine (JSR283 wise) for Oak to defer the node type test until save, it might still affect clients.

          With rev 1453337 I also added a test demonstrating the change to the CompatibilityIssuesTest test class.

          Show
          alex.parvulescu Alex Parvulescu added a comment - - edited Linked to SLING-2763 to refer to a potential backward compatibility issues. While it's fine (JSR283 wise) for Oak to defer the node type test until save, it might still affect clients. With rev 1453337 I also added a test demonstrating the change to the CompatibilityIssuesTest test class.
          Hide
          bdelacretaz Bertrand Delacretaz added a comment -

          FWIW a while ago I created a test module in Sling, that runs the exact same tests on a Jackrabbit repository and then on Oak [1].

          I'd be open to giving Oak committers write access to that module (if the Sling PMC accepts) if you guys think it's useful.

          [1] http://svn.apache.org/repos/asf/sling/trunk/bundles/jcr/it-jackrabbit-oak/

          Show
          bdelacretaz Bertrand Delacretaz added a comment - FWIW a while ago I created a test module in Sling, that runs the exact same tests on a Jackrabbit repository and then on Oak [1] . I'd be open to giving Oak committers write access to that module (if the Sling PMC accepts) if you guys think it's useful. [1] http://svn.apache.org/repos/asf/sling/trunk/bundles/jcr/it-jackrabbit-oak/
          Hide
          jukkaz Jukka Zitting added a comment -

          All subtasks resolved.

          Show
          jukkaz Jukka Zitting added a comment - All subtasks resolved.
          Hide
          alex.parvulescu Alex Parvulescu added a comment -

          bulk close for the 1.0 release

          Show
          alex.parvulescu Alex Parvulescu added a comment - bulk close for the 1.0 release

            People

            • Assignee:
              Unassigned
              Reporter:
              mduerig Michael Dürig
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Time Tracking

                Estimated:
                Original Estimate - 24h
                24h
                Remaining:
                Remaining Estimate - 24h
                24h
                Logged:
                Time Spent - Not Specified
                Not Specified

                  Development