Subject: URP, Replication Update Protocol, and atomic changes

From: "John McGarvey" <[email-masked]>
Date: Mon, 5 Mar 2001 13:09:15 -0500

Applications sometimes need to make atomic changes to an entry.  One
example is a simple counter, a single valued attribute that is incremented
by replacing the current value with the incremented value.  This works fine
in a single master case.  It does not work in a multimaster case using URP,
because the value may be incremented, say from 4 to 5, on one of the
servers and then, before that change has been propagated via replication,
the counter might be incremented on a different server, also from 4 to 5.
The value after replication would remain 5, but the desired result is 6.
The problem of atomic changes to entries has been thoroughly discussed on
the list.

URP does not provide any application workaround for this problem.  This is
troubling.  I would like to suggest a workaround for use in URP.  Suppose,
for any replication context, one server is defined as the master for any
changes requiring atomicity.  We would have to define a means to advertise
the location of the master.  If application needs, say, to increment a
counter, it should be written make that change on the atomicity master for
that replication context.  If that master is unavailable, the change must
not proceed.  Changes not requiring atomicity -- probably the great
majority of writes to the directory -- could proceed on any peer master.
Of course, this approach to atomicity does not guarantee that conflicting
changes do not occur concurrently on other servers, because some
applications may fail to use the mechanism.  But, for applications that do
exploit this approach consistently, reliable counters and other data
requiring atomic change could be stored in the directory.

This approach could be extended to make an atomic change to a collection of
entries, so as to offer simple transactional semantics without 2 phase
commit:

[control to begin atomic change] operation operation operation [control to
end atomic change]

If all of these grouped operations are on directory entries within
replication contexts for which a single server is the atomicity master,
that master evaluates the collection of changes, applying all or none of
them.  If the current server is not the atomicity master for all of the
affected entries, it rejects, or possibly redirects, the group of
operations. Of course, as for a single entry, conflicting changes may occur
concurrently on other servers, if applications fail to use the mechanism.

When changes corresponding to a group of operations are replicated, they
should be applied as a unit, so that an application reading data from the
directory is not returned data corresponding to an intermediate state in
which some but not all entries affected by the group of operations have
been updated.  LDUP Replication Update Protocol currently groups changes to
a single entry, so that such changes can be applied as a unit, but it does
not provide a means of grouping changes to a collection of entries.
Perhaps the protocol should be extended to support this kind of grouping.

This suggestion would require two changes to the current LDUP drafts: (1) a
means of identifying the atomicity master for a given replication context,
and (2) a change to the replication update protocol to permit grouping of
changes to multiple entries so that they can be treated as a unit.

-- John McGarvey