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 >
