Hi,
The following should work:
- use a node type without _orderable_ child nodes
- in each node, add a property "created" with the timestamp plus a unique
id
- to get the first entry, use a query ("order by created")
This should scale well once synchronous, orderable indexes are implemented.
The problem with orderable child nodes is that in a cluster, this either
gets many conflicts or doesn't scale well. The problem with using a tree
structure ("/queue/2014-08/06T13/40_45") is that it's hard to implement.
Please note that in Oak, right now, orderable indexes are not synchronous.
But I think this is a problem we can and should solve soon. Orderable
child nodes should also be improved in my view, but that's a area where we
know there are limitations.
Regards,
Thomas
On 05/08/14 13:37, "Michael Dürig" <[email protected]> wrote:
>
>
>On 5.8.14 12:22 , Christian Keller wrote:
>> Jumping in here, where the thread developed to a discussion about the
>>repository implementation of orderable Nodes.
>> I like to come back to the use-cases needed.
>>
>> These can be summarized that I expect a certain order upon access of
>>the Node's NodeIterator.
>
>That order is up to the implementation and applications should not
>depend on this. See 23.5 Non-orderable Child Nodes:
>http://www.day.com/specs/jcr/2.0/23_Orderable_Child_Nodes.html#23.5%20Non-
>orderable%20Child%20Nodes
>
>> 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.
>
>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 <[email protected]>
>> Gesendet: Montag, 4. August 2014 20:02
>> An: [email protected]
>> Betreff: Re: How to implement a queue in Oak?
>>
>> Hi,
>>
>> On Mon, Aug 4, 2014 at 8:04 AM, Felix Meschberger <[email protected]>
>>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
>>
