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

Reply via email to