jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Dürig (Commented) (JIRA) <j...@apache.org>
Subject [jira] [Commented] (OAK-14) Identify and document changes in behaviour wrt. Jackrabbit 2
Date Wed, 14 Mar 2012 13:34:38 GMT

    [ https://issues.apache.org/jira/browse/OAK-14?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13229181#comment-13229181
] 

Michael Dürig commented on OAK-14:
----------------------------------

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
                
> Identify and document changes in behaviour wrt. Jackrabbit 2
> ------------------------------------------------------------
>
>                 Key: OAK-14
>                 URL: https://issues.apache.org/jira/browse/OAK-14
>             Project: Jackrabbit Oak
>          Issue Type: Task
>            Reporter: Michael Dürig
>
> 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.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

Mime
View raw message