________________________________________ Von: Michael Dürig <mdue...@apache.org> Gesendet: Dienstag, 5. August 2014 13:37 An: oak-dev@jackrabbit.apache.org Betreff: Re: AW: How to implement a queue in Oak?
>> In any cases I had in CQ there was never a requirement of strict ordering. >> But it was used to allow a user defined order: The Page-Order in the >> navigation. >> So I wonder if a basic non strict order to allow for JCR order support is >> sufficient. >> >> For any other orders I wonder if an additional method to >> Nod#getNodes(Comparator) would not be sufficient. > >As I don't think this can scale to many child nodes, you could use an > orderable node type as well. For sake of correctness: What you suggest is something different: The orderable NodeType is the order of the persistence. Where I say offer a convenient way to give an arbitrary order, than applications may stop trying to use persistence to implement their specific order needs. Michael > > With this you can move the burden of ordering on access. > A time sequence for child-node could be easily achived on the jcr:created > Property > > Regards > Christian > > ________________________________________ > Von: Jukka Zitting <ju...@zitting.name> > Gesendet: Montag, 4. August 2014 20:02 > An: oak-dev@jackrabbit.apache.org > Betreff: Re: How to implement a queue in Oak? > > Hi, > > On Mon, Aug 4, 2014 at 8:04 AM, Felix Meschberger <fmesc...@adobe.com> wrote: >> I have the impression, that JCR itself can adequately solve the problem >> using ordered child nodes. >> >> The problem is not JCR per-se but the implementation and the early-on >> decision to not optimize >> the use case of ordered child nodes (in favor of having support for >> optimized implementation of >> the unsorted case). > > The preference against ordering is more than just a performance > optimization. Maintaining strict ordering semantics is impossible in > an eventually consistent system with no global synchronization. For > example, if two clients on different cluster nodes add entries at the > end of the list at the same time, which entry should come first? And > how do we ensure that the ordering remains consistent across all > clients? > >> Now with Oak, we also have customizable indices. Would it be possible to >> define an ordering >> property, index that property and then use a query to get these nodes. The >> query could be >> created such that the ordering property index would be considered (only). As >> a result we get >> quick and transparent sorted nodes? > > Yes, that's possible. My "order by node name" suggestion works roughly > in the same way. The problem with these approaches is that you won't > get strict ordering semantics without some external synchronization or > a global clock to decide how the values of the ordering property > should be assigned. However, it sounds like in Carsten's case relaxed > ordering semantics based on millisecond timings from the system clock > should be good enough. > > BR, > > Jukka Zitting >
