I don't yet have a proper proposal, but maybe what could be done may be something similar to what Davide has done with regards to the ordered index (using a skiplist), that is defining a specific structure of the nodes, together with a specific implementation, that avoids having to use sortable node types but is an inherently sorted structure, e.g. binary search tree. Any opinions?
Regards, Tommaso 2014-08-01 7:56 GMT+02:00 Carsten Ziegeler <cziege...@apache.org>: > I'm wondering if anyone has a good idea how to model a queue with efficient > operations in JCR - or is JCR not suited for this use case? > > Regards > Carsten > > > 2014-07-30 15:57 GMT+02:00 Carsten Ziegeler <cziege...@apache.org>: > > > Using a different storage than JCR would be easy in my case, however I > > *want* to use JCR > > > > Carsten > > > > > > 2014-07-30 14:55 GMT+02:00 Lukas Smith <sm...@pooteeweet.org>: > > > > Hi, > >> > >> I can totally see that it might be useful to be able to go through the > >> Oak/JCR API to have a queue but maybe this is stretching Oak a bit far > if > >> you end up with 1k+ queues. > >> > >> However I think it would be great to look more into federation for this. > >> I think ModeShape supports this quite well already, ie. being able to > hook > >> in another JCR tree, a file system, a git repository, CMIS .. I am sure > >> that it would also be possible to implement on top of some MQ standard. > >> > >> see also https://docs.jboss.org/author/display/MODE/Federation?_sscc=t > >> > >> regards, > >> Lukas > >> > >> > On 30 Jul 2014, at 14:41, Angela Schreiber <anch...@adobe.com> wrote: > >> > > >> > hi carsten > >> > > >> > if you are expecting your nodes to be in a given order (e.g. the > >> > order of creation) you need to have a parent that has orderable > >> > children... in which case we don't make any promises about huge > >> > child collections... it will not work well. > >> > > >> > if you don't have the requirement of ordered children, you can > >> > have _many_ but need to make sure that your parent node doesn't > >> > have orderable children (e.g. oak:Unstructured)... but then you > >> > cannot expect that new children are appended at the "end of the > >> > list"... there is no list and there is not guaranteed order. > >> > > >> > i guess you have a little misunderstanding when it comes to > >> > the concept of orderable child nodes -> JSR 283 will be your friend. > >> > > >> > regards > >> > angela > >> > > >> >> On 30/07/14 13:27, "Carsten Ziegeler" <cziege...@apache.org> wrote: > >> >> > >> >> Hi, > >> >> > >> >> afaik with Oak the too many child nodes problem of JR2 is solved, > >> >> therefore > >> >> I'm wondering what the best way to store a queue in the repository > is? > >> >> > >> >> In my use cases, there are usually not many items within a single > >> queue, > >> >> let's say a few hundreds. In some cases the queue might grow to some > >> >> thousands but not more than maybe 20k. > >> >> > >> >> The idea is that new entries (nodes) are added to the end of the > queue, > >> >> and > >> >> processing would read the first node from the queue, update the > >> properties > >> >> and once done, remove it. > >> >> > >> >> My initial design was to simply store all entries as sub nodes of > some > >> >> queue root entry without any hierarchy. addNode should add them at > the > >> end > >> >> and simply iteration over the child nodes of the root gives the first > >> >> entry. No need for sortable nodes. > >> >> > >> >> Does this make sense? Is there anything else to be considered? > >> >> > >> >> Regards > >> >> Carsten > >> >> -- > >> >> Carsten Ziegeler > >> >> Adobe Research Switzerland > >> >> cziege...@apache.org > >> > > >> > > > > > > > > -- > > Carsten Ziegeler > > Adobe Research Switzerland > > cziege...@apache.org > > > > > > -- > Carsten Ziegeler > Adobe Research Switzerland > cziege...@apache.org >
