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

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

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:SHARIPRIYA@xxxxxxxxxx]
> Sent: Friday, 30 June 2000 16:08
> To: steven.legg@xxxxxxxxxxxxx
> 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]
>
>
>