RE: various comments (was Re: What's going on? - StatusofRequirements...)

["Steven Legg" <steven.legg@xxxxxxxxxxxxx>]

Hi,

Comments in-line ...

> -----Original Message-----
> From: Haripriya S [mailto:SHARIPRIYA@xxxxxxxxxx]
> Sent: Thursday, 13 July 2000 16:07
> To: steven.legg@xxxxxxxxxxxxx
> Cc: ietf-ldup@xxxxxxx; alison.payne@xxxxxxxxxxxxxxxx
> Subject: RE: various comments (was Re: What's going on? -
> StatusofRequirements...)
> 
> 
> Steven,
> 
> <steven>The remaining (N - M) replicas would not be allowed 
> to perform any
> strong consistency updates because they wouldn't be able to obtain
> a quorum of M replicas: M > N/2 implies (N-M) < M .
> However, loose consistency updates would be allowed at the 
> (N-M) replicas,
> which might invalidate strong consistency updates performed by the M
> replicas. I would regard this as a case of one application 
> stomping over
> another application because it is unaware/uncaring of the second
> application's semantics and constraints. This sort of thing 
> is a problem
> even in the single master case, though admittedly the 
> multi-master case
> raises some situations that wouldn't occur on a single master.
> 
> - As transaction is an add-on for a directory, it should work 
> even in cases a client is not aware of strong or weak 
> consistency. One model that can be followed is:
> 
> - reads are weakly consistent unless the client knows and 
> asks for strong consistency.

We obviously have a choice for the default consistency behaviour.
Since current applications operate in an environment without multiple
operation transactions, i.e. weak consistency, it seems reasonable to
assume weak consistency for reads. It would still be prudent for
server implementations to provide a means for enforcing strong
consistency on a per user, per attribute type, per application, per
whatever basis, for the sake of broken applications that don't realize
they are operating in a weak consistency environment. I'd be happy to
leave the details up to vendors to decide for themselves.

In X.500 terms, the dontUseCopy service control would also be a good
indicator of whether strong consistency is required for a read.

> - writes even if not specified by client should result in 
> strong consistency.

Atomicity is expected for updates so defaulting to strong consistency
for updates is reasonable.

> 
> - One way in which this can be done is i. use a normal read 
> in case of no or weak consistency reads. ii. use the quorum 
> based aproach you mentioned if client requests strong 
> consistency read. iii. use a timestamps based approach for 
> atomicity of writes.
> 
> - if a transaction makes n modifies to the directory (add, 
> modify or del) all these n modifies should have consecutive 
> or same CSNs.

Agreed.

> The CSNs will have the time at which the 
> transaction ended.Thus if server 1 makes changes to n items 
> in set N by a transaction beginning at time t1 and ending at 
> t2, and server 2 makes change to item n1 belonging to set N 
> at time t3, then if t2 > t3, then the effect of the change at 
> t2 will be overridden by the transaction at server 1. If t2 
> is less that t3, then it is as if the lone change to n1 came 
> after the transaction completed, so the result is as 
> expected.

Not really. The transaction at server 2 used the state of n1 as it
was at time t1. If the transaction at server 2 is deemed to have occurred
"after" the transaction at server 1 then it is only correct from a strong
consistency point of view if it used the state of n1 as it was at time t2
on server 1. I'm assuming that the transactions are doing some reading.
Purely write-only transactions are rare.

> This approach could be used even if some of the 
> servers are down or inaccessible at the moment.
> 
> <steven>My original thought was to allow applications to 
> request whether or not
> their operations should be executed with strong consistency, 
> but I think
> it would also be useful if applications and/or administrators 
> could register
> what entries or attributes they want the server(s) to protect 
> by insisting
> that ALL operations against those directory items, even those 
> explicitly
> requesting loose consistency, are performed with strong consistency.
> In this way an application could block loose consistency 
> updates in any
> currently inaccessable (N-M) subset of the replicas.
> 
> - Specifying a set of entries or attributes as forming a 
> transaction group may be difficult. Imagine the case where 
> the transaction's need is to preserve consistency between a 
> user and its group object at all times. if the user has a 
> groupmembership attribute, and the group has a member 
> attribute, these have to be changed together for the change 
> to be consistent. But it is difficult to specify this 
> relationship in terms of entry names because it has to be 
> said like "if entry e1 is the value of a member attribute of 
> a group g1, and e1 is a user, then the groupmembership 
> attribute of e1 should be updated along with the member 
> attribute of g1", which is difficult.

I've been thinking along the lines of using a set of search operations to
specify the directory data to protect. The basic idea being that the
server blocks any update that would cause the result of
those searches to change. How that gets implemented internally is a
separate matter.

If I was interested in protecting two particular entries e1 and g1 then
I could use two search specifications. The first would have a base object
of g1 and a filter of (member=e1). The second would have a base object of
e1 and a filter of (groupmembership=g1).

More likely you want to protect the relationship for all members of g1's
group. Someone (Bruce maybe?) put together an ID on a matching rule that
chased down DN links. I forget the details, but maybe that would enable
a precise search specification of the relationship between g1's member
list and the member's groupmembership attribute values. In any case, a
more general search specification will do, at the cost of potentially
lower update concurrency. A subtree search with filter on member present
or groupmembership present and returning only member and groupmembership
will do the trick. That effectively locks out any change to those two
attribute types.

Regards,
Steven

> 
> Regards,
> Steven
> 
> - Thanks and Regards,
> - Haripriya
> 
>