Re: LDAP Requirements comments

=================
Ed Reed
Reed-Matthews, Inc.
+1 585 624 2402
http://www.Reed-Matthews.COM
Note:  Area code is 585

>>> "Kurt D. Zeilenga" <[email protected]> 11/21/01 04:47PM >>>

...

  Multi-Master Replication - A replication model where entries
  can be written and updated on any of several master replica
  copies without requiring communication with other master
  replicas before the write or update is performed. 

By this definition, multi-master replication with Transactional
data consistency is not multi-master replication.  Suggest:
  Multi-Master Replication - A replication model that assumes
  multiple servers, each a master, allow LDAP write access to
  the replicated data.

  Slave (or Read-Only) Replica - A replica that cannot be
  directly updated via LDAP requests. Changes may only be made
  via replication from a master replica. Read-only replicas may
  occur in both single- and multi-master systems. 

I suggest s/may/can/ in both instances.  I also note that there
likely should be an explicit requirement that LDUP support
multi-master systems with slave replicas.

....

<eer> I'd argue that, indeed, transactional data consistency
among multiple DSA instances holding a replica of a the same
area of replication is, infact, not a subject of multi-master
replication, but rather a characteristic of a single master
replica, which happens to be transactionally spread among
several servers.  To the rest of the LDUP world, the entire
set of servers cooperating in maintaining the transactional
replica should be treated as just that - a single replica with
possibly several different network addresses by which it 
can be reached.

That approach leaves the entire question of how the transactions
are defined, how they're propagated, how they are rolled back, and
how they interoperate with LDUP supporting servers as a local matter,
and is entirely outside the scope of LDUP.

To be absolutely clear:  I'd like to leave transactions entirely out of
LDUP, and to use a perspective like the one I've outlined above as
the way of viewing transaction-supporting servers.

Why?  Because by their very definition, talking to any one DSA server
participating in the transactionally consistent support of a replica
is just like talking to any other DSA of the transactional set.  Other
that each DSA may be holding different sets of other replication and
so have different characteristics when it comes to handling cross-area
moves of entries, and a different set of external references to
manage.  Those differences may yield different performance
characteristics, but because they're bound to all the other DSAs in
the transaction set of servers they still behave the same from the
perspective of any other LDUP replica of the area of replication.

So - I would prefer to keep the current definition of the Master Replica
insofar as this aspect of the definition is concerned, because it
explicitly encodes our operating assumption - that there is no requirement
for communication with other master replicas before the write or
update is performed.

W/R/T the slave definition, I think it specifically does make clear that
slave replicas may occur in multi-master systems.  I have no problem with
adding a requirement to support the notion, as that is implicit in my own
thinking.

</eer>