Subject: RE: Issue 105 (CLOSE and DELEGRETURN)

From: "Noveck, Dave" <[email-masked]>
Date: Fri, 19 Jul 2002 14:01:18 -0700

> Issue 105 is in your "should not hold up the spec" list.
> 
> >>>>> "Dave" == Dave Noveck <Noveck> writes:
>
>    Dave> Issue 105: Clarify the use of CLOSE (with delegation
>    Dave> stateid) as a means for the client to return a delegation to
>    Dave> the server. Is the client required to CLOSE for both the
>    Dave> original OPEN and the delegation stateid or is the
>    Dave> delegation stateid CLOSEd when the CLOSE is done for the
>    Dave> OPEN stateid? Or should the client CLOSE with the stateid
>    Dave> returned from OPEN as well as DELEGRETURN with the
>    Dave> delegation stateid?
> 
>    Dave>      The last of these is correct.  I don't see the problem.
>    Dave>      Delegations are returned with DELEGRETURN and OPEN's
>    Dave>      are bracketed with CLOSE's.  What more needs to be
>    Dave>      said?
>
> If this is the issue I'm thinking of, there has been some difference
> of opinion as to how long the client can hold onto the delegation.

Until it is recalled or the client decides to voluntarily return it,
period.

> > In particular, can the client 
> 
>     CLOSE the original reference

Yes, but what I agree is unclear in the spec's presentation is the
distinction among the operations that are being performed (e.g.
a close() on the file), the requests that would in the absence 
of the delegation be passed to the server, in this case a CLOSE,
and the requests that might be sent to the server as part of
unwinding its delegation, in order to update the servers state to
match that established by the delegated client, which in this case
would also be a CLOSE.

> and then
>
>     OPEN using CLAIM_DELEGATE_CUR with the delegation from the
>      original reference

> It seems wrong to me that the client keeps its delegation even after
> issuing a CLOSE on the file. 

Are you saying it is wrong to keep the delegation after the user 
closes the file?  Why would that be wrong?  The whole purpose of
the delegation is that a file which is going to be used a lot
(including openas and closes) may be managed by the delegated
client without burdening the server.

Or are you saying that it is wrong to keep the delegation after
issuing the CLOSE request?  As long as the delegation is held,
the only function of that CLOSE is as part of updating the
servers collection of state for the file to match that of the
client.  In the spec, it presents this as happening as part
of returning the delegation and it can be done this way.
However, once the close() occurs, that open is gone never to
be revived so it makes sense for the client to send the CLOSE,
even if he has tons of of OPEN's that happened under the 
delegation.  It doesn't make sense for him to send those,
because it is probable that matching close's will occur
before returning the delegation, obviating the need for the
server to know anything about those OPEN's.

However, if the close() happens first, then the cleitn 
must do the CLOSE before the DELEGRETURN, even if it is
only a little before (e.g. in the previous op in the COMPOUND).

To see why this is, suppose somone does an OPEN specifying
DENY=ALL and that this OPEN has an assoicated delegation.
If a close() now occurs, and then some other client tries
to do an open and the delegation is recalled, then if
the order is CLOSE-DELEGRETURN, then when the delegation
is returned and the copen from the other cleint is processed,
the server will know that there is no conflicting opem.
On the other hand, if the order were DELEGRETURN-CLOSE,
then once the DELEGRETURN were processed the conflicting 
open would be processed and encounter the open still with
DENY=ALL, resulting in SHARED_DENIED, which would be wrong
if the close() had already happened.

> > I seem to be in the minority on this,
> > and I can live with that behavior being allowed, but it does seem
> > important for interoperability that the spec clarify this.

I'll try to come up with spec changes that put you more clearly
in the minority :-)

---

From: [email-masked]
Date: Fri, 19 Jul 2002 16:34:55 -0700

>>>>> "Dave" == Dave Noveck <Noveck> writes:

    Dave> Or are you saying that it is wrong to keep the delegation
    Dave> after issuing the CLOSE request?

Right, that's what bothered me.  But your example makes sense, and if
the client can hold the delegation for a few milliseconds after the
CLOSE, I guess there's no harm in letting it hold the delegation
arbitrarily long.

    Dave> I'll try to come up with spec changes that put you more
    Dave> clearly in the minority :-)

Sounds good.

mike