Update multiple nodes transactionally

[RedShift1]

Hello

I've been playing around with the OPC UA Server Example (https://github.com/eclipse/milo/tree/master/milo-examples/server-examples). Updating a single node's value seems simple enough:

node.setValue(new DataValue(1234));

But what if I need to update multiple nodes at the same time? For example I have a list of 10 nodes that need to updated every 100 ms, but when a client reads while the updates are ongoing, it shouldn't get for example 3 new values and 7 old values, because the update loop was still running whilst the client was reading at the same time. For example consider this sequence of events:

node1.setValue(new DataValue(20));
node2.setValue(new DataValue(20));
node3.setValue(new DataValue(20));
-> Client reads all 3 nodes and gets 20, 20, 20

node1.setValue(new DataValue(21));
node2.setValue(new DataValue(21));
-> Client reads all 3 nodes and gets 21, 21, **20**
node3.setValue(new DataValue(21));

How can this situation be avoided? The client sees either all the old values or all the new values, but not the inbetween state.

[kevinherron]

You would need to install an AttributeFilter on all of these Nodes that acquired a common lock or synchronized by some other means before reading.

A more appropriate solution would probably be to use a single Node with a structure value that you can update atomically, but defining and using custom types is difficult enough to not be worth pursuing in the current 0.6.x series.

[kevinherron]

Also worth noting - unless you are in control of the client as well, I wouldn't assume it's doing repeated reads to acquire these values instead of using a Subscription with Monitored Items.

[RedShift1]

Thanks for the quick reply. You gave me another idea though with subscriptions, what about an "updateTimestamp" node that is always updated as the last node. When the client receives an update to this node, it knows all the other nodes are current. This assumes that the order of operations remains consistent, ie when the update loop runs, the client receives these updates in the same order as the update loop on the server. Is that the case?

[kevinherron]

You could do something like that, but now you're well into the territory where the client must know about the server's implementation details and you have to document it somewhere.

The locking could look something like:

        ReadWriteLock readWriteLock = new ReentrantReadWriteLock();

        UaVariableNode node1 = null;
        UaVariableNode node2 = null;
        UaVariableNode node3 = null;

        node1.getFilterChain().addLast(AttributeFilters.getValue(ctx -> {
            readWriteLock.readLock().lock();
            try {
                return (DataValue) ctx.getAttribute(AttributeId.Value);
            } finally {
                readWriteLock.readLock().unlock();
            }
        }));

        readWriteLock.writeLock().lock();
        try {
            node1.setValue(new DataValue(Variant.ofInt32(42)));
            node2.setValue(new DataValue(Variant.ofInt32(42)));
            node3.setValue(new DataValue(Variant.ofInt32(42)));
        } finally {
            readWriteLock.writeLock().unlock();
        }

and you could probably make it less verbose by making a custom AttributeFilter class to handle the locking:

    class ReadWriteLockAttributeFilter implements AttributeFilter {
        private final ReadWriteLock readWriteLock;

        ReadWriteLockAttributeFilter(ReadWriteLock readWriteLock) {
            this.readWriteLock = readWriteLock;
        }

        @Override
        public @Nullable Object getAttribute(AttributeFilterContext ctx, AttributeId attributeId) {
            if (attributeId == AttributeId.Value) {
                readWriteLock.readLock().lock();
                try {
                    return ctx.getAttribute(AttributeId.Value);
                } finally {
                    readWriteLock.readLock().unlock();
                }
            } else {
                return ctx.getAttribute(attributeId);
            }
        }
    }

then it's just:

node2.getFilterChain().addLast(new ReadWriteLockAttributeFilter(readWriteLock));

[kevinherron]

Doh, I'm not sure what I was thinking, this doesn't fully solve the problem. You'd have to acquire the read lock in AddressSpace::read, assuming the client is doing a bulk read, not inside the filters.