jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Angela Schreiber <anch...@adobe.com>
Subject Re: Inconsistent behavior upon moving nodes
Date Tue, 05 Feb 2013 18:27:31 GMT
hi michael

thanks for the information. i agree that 3) currently seems the
way to go if we want to address the move issue.

from my experience move operations are rather rare (as already
noticed by jukka). in combination with the fact that our main use
case in general involves very shorted-lived sessions i would assume that
3b should be feasible without hampering our overall goals. i would
treat this similar to namespace remappings: the default should be
a no-op but it might get expensive if there are a lot of transient
move operations pending... in general i would prefer such a limitation
over the compatibility break in particular since new and existing
nodes behave differently and the issues as described in OAK-606 and
OAK-607 are likely to cause wired behavior that will be hard to track.


On 2/5/13 6:10 PM, Michael Dürig wrote:
> Hi,
> On 5.2.13 16:39, Michael Dürig wrote:
>> AFAICT we have three possibilities here:
>> 1) drop support for tracking nodes across moves (AKA OAK-391),
>> 2) track nodes through weak reference,
>> 3) come up with another ingenious approach of tracking nodes across moves.
> Some more perspective on 3):
> Every approach will either (a) need to notify node instances about moves
> or (b) each node instance would need to check whether a move occurred
> after the respective instance has been acquired.
> (a) The first approach requires some kind of tracking of all node
> instances so it will be basically option 2) from above.
> (b) The second approach requires tracking of all move in a session and
> some information to determine whether a move has happened before a node
> was acquired or after and thus whether that move affected that node or not.
> Michael

View raw message