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 <[email protected]>: > 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 <[email protected]> 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" <[email protected]> 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 > >> [email protected] > > > -- Carsten Ziegeler Adobe Research Switzerland [email protected]
