[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Abandon Modify
At 09:09 AM 2002-07-08, Mark Wahl wrote:
>I don't see why it has to do that from your description. Do you mean
>that the client is sending both requests with the same message ID?
No. My example was flawed.
The root of the problem is the protocol's assumption that
any operation can be immediately abandoned. However, some
operations may take significant time/resources to abandon
and some operations may not be abandonable once some amount
of processing has been performed.
Unless the server serializes operations, I don't see how it
could implement Abandon semantics.
I've changed the request to a modDN (as whole subtree rename
operations are quite expensive in many implementations).
Consider a client which sends:
modDN request (id=1000)
abandon request (id=1001) for modify request (id=1000)
search request (id=1002)
If the client receives a search response for id=1002 before any
response for the modDN request id=1000, it is to assume that
the id=1000 is reusable as the modDN request is assumed to
be abandoned.
However, if the server doesn't serialize these operations, the
modDN request may still be in progress of completion or abandonment.
If so, a client were to send a second search request with id=1000,
it would get protocol error (because the message id is still in use).
So, there are the changes I suggest:
Section 4.1.1:
Replace:
A client MUST NOT reuse the message id of an abandonRequest or of the
abandoned operation until it has received a response from the server
for another request invoked subsequent to the abandonRequest, as the
abandonRequest itself does not have a response.
with:
A client MUST NOT reuse the message id of an abandonRequest or of
an abandoned operation, unless it has subsequently completed
(successfully or not) a bind operation, as these operations may
still be in progress.
and replace Section 4.11 (in total) with:
4.11. Abandon Operation
The function of the Abandon Operation is to allow a client to request
that the server abandon an outstanding operation. The Abandon
Request is defined as follows:
AbandonRequest ::= [APPLICATION 16] MessageID
The MessageID MUST be that of a an operation which was requested
earlier in this connection.
(The abandon request itself has its own message id. This is distinct
from the id of the earlier operation being abandoned.)
As there is no response defined in the Abandon Operation and
no response to the abandoned operation, there is no clear
indication provided to the client as to whether the request
was (or will be) honored or not.
Not all operations can be abandoned or only abandonable during
certain stages of processing. In particular, servers may not
be capable of rolling back complex modifications to the DIT
once they have been committed.
Servers are not required to be able and willing to honor all
(or any) Abandon request. If the server is unable or unwilling
to honor the Abandon request, the server MUST ignore the Abandon
request. That is, the operation for which the client requested
to be abandon is to be processed as if no Abandon request was
made.
A server MAY abandon operation even after it has provided
intermediate responses for that operation. Of course,
the server MUST ensure that only properly encoded LDAPMessage
PDUs are transmitted. For example, a server which receives
an Abandon request (which it intends to honor) for an Search
Operation in the midst of transmitting entry and reference
results may cease transmitting results but must ensure that
LDAPMessage PDUs sent are properly encoded.
Clients MUST NOT send abandon requests for the same operation
multiple times, and MUST also be prepared to receive results from
operations it has requested to be abandoned (since the operation
to abandon may have completed before the Abandon request was
received or the Abandon request not honored).
Servers MUST discard abandon requests for message IDs they do not
recognize, for operations which cannot be abandoned, and for
operations which have already been abandoned.