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