Thanks Jukka, in my case I have several producers and a single consumer, so your second suggestion should do the trick. Can you make any comments about the performance of such a solution? I assume Node#getChildNodeNames() is pretty cheap, what about the addNode, getNode, removeNode methods?
Carsten 2014-08-01 15:03 GMT+02:00 Jukka Zitting <[email protected]>: > Hi, > > On Wed, Jul 30, 2014 at 7:27 AM, Carsten Ziegeler <[email protected]> > wrote: > > Does this make sense? Is there anything else to be considered? > > You didn't mention whether you expect the queue to be concurrently > accessed. > > If there is just a single producer and a single consumer, then you > could just name the entries using a running sequence number, and > there's no need for repository-level ordering. For example: > > void produce(Node queue) { > long number = queue.getProperty("writeCount").getLong(); > queue.addNode("entry" + number); > queue.setProperty("writeCount", number +1); > queue.getSession().save(); > } > > // consumes all entries currently in the queue, call again later to > continue > void consume(Node queue) { > long original = queue.getProperty("readCount").getLong(); > long number = original; > while (queue.hasChild("entry" + number)) { > queue.getNode("entry" + number++).remove(); > } > if (number != original) { > queue.setProperty("readCount", number); > queue.getSession().save(); > } > } > > If there is a single consumer but multiple concurrent producers, you > could name the entries using timestamps and do explicit ordering in > the consumer: > > void produce(Node queue) { > queue.addNode("entry-" + System.currentTimeMillis() + "-" + > UUID.randomUUID()); > queue.getSession().save(); > } > > // consumes all entries currently in the queue, call again later to > continue > void consume(Node queue) { > List<String> names = Lists.newArrayList(queue.getChildNodeNames()); > Collections.sort(names); > for (String name : names) { > queue.getNode(name).remove(); > } > queue.getSession().save(); > } > > Note that the above does not guarantee strict ordering between entries > produced at roughly the same time (typically within a few dozens of > milliseconds). For that you'll need more explicit synchronization > between the producers. Similarly, supporting concurrent consumers will > likely require some extra synchronization between the consumers as the > repository itself does not provide strict guarantees in this area > (unless you want to rely on the features of specific backends like the > TarMK). > > -- > Jukka Zitting > -- Carsten Ziegeler Adobe Research Switzerland [email protected]
