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

From: "Steven Legg" <[email-masked]>
Date: Mon, 3 Jul 2000 11:04:35 +1000

Hi,

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.

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.

Regards,
Steven

> -----Original Message-----
> From: Haripriya S [mailto:[email-masked]]
> Sent: Friday, 30 June 2000 16:08
> To: [email-masked]
> Subject: RE: various comments (was Re: What's going on? - Status
> ofRequirements...)
>
>
> Hi,
>
> What happens in this case where there are N replicas and only
> M are connected to the given primary at this time? In this
> case, will it not be the case that the remaining N - M
> replicas could have changed an entry in the transaction with
> a later timestamp, and could also be servicing a client for
> this data? Or am I missing something?
>
> Thanks and Regards,
> Haripriya S.
>
> [snip]
>
> This is the sequence of events for a user update request requiring or
> requesting strong consistency:
>
> The receiving replica (let's call it the primary) opens a session with
> each of the other replicas and sends a request for all update
> primitives
> up to and including the latest change to the target entry.
> This is just a
> variation on a regular LDUP session. However the other
> replicas will also
> lock the target entry to prevent any local changes to it. Some sort of
> deadlock detection will be necessary.
>
> The primary replica applies all the primitives it has
> received and then
> attempts the user request. If it fails with an error the sessions with
> the other replicas are closed and they drop the locks on the
> target entry.
> If the request succeeds the primary server sends
> the primitives up to and including the ones generated from the current
> user request, then closes the sessions causing the locks to be
> released. If the primary doesn't send the latest primitives the other
> replicas will just import them the next time they action a strong
> consistency update on the same entry. Two-phase commit isn't required.
>
> Handling transactions is straightforward. The initial request from the
> primary replica specifies a range of affected entries (maybe with
> something like a search filter) instead of just the one target entry.
> The primary is also allowed to send multiple requests within the same
> session since it won't generally know all the entries affected by
> a transaction at the beginning.
>
> The above scheme requires all updatable replicas to be
> available to perform
> a strong consistency update but there is a more general scheme that
> allows some of the replicas to be unavailable. If there are N replicas
> then it is only necessary to contact M (M > N/2) of them to
> make an update
> provided N-M+1 of them are contacted before evaluating any strong
> consistency query. The original description was the special
> case of M = N.
>
> [snip]
>
>
>

---

From: "Haripriya S" <[email-masked]>
Date: Thu, 13 Jul 2000 00:06:52 -0600

Steven,

<steven>The remaining (N - M) replicas would not be allowed to perform any

- 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.
- writes even if not specified by client should result in strong consistency.

- 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. 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. 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

- 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.

Regards,
Steven

- Thanks and Regards,
- Haripriya