Subject: I found the lock related email

From: [email-masked]
Date: Sun, 28 Jul 2002 15:24:50 -0400 (EDT)

Ok, I found the email related to locking and it refers to the stateid as
referring to the "set of locks held by a given lockowner for a file".

Does that sound right? (This implies that my code is close, but needs to
change slightly for the case of the same owner holding multiple locks
on the same file.)

It also hints that the seqid# in the stateid is used to reflect a change
of stateid. This suggests that it is not used for operation ordering?
(I also have trouble seeing when a stateid would change. Is it to change
 via incrementing the seqid# in it whenever a lock is added/deleted/changed
 for that <lockowner,file>?)

Sorry to bother you with this stuff, but I'm still confused. (And appologies
for posting the last message before I found the email from last year, which
had some answers in it.)

Thanks again for any help, rick

---

From: David Robinson <[email-masked]>
Date: Sun, 28 Jul 2002 20:47:34 -0500

> change slightly for the case of the same owner holding multiple locks

That is correct, the stateid is supposed to be used as a shorthand
between the client and server to indicate the current state.  As such,
for every lockowner/file there is only one valid stateid. Adding
new locks changes the stateid and invalidates the previous stateids.

>  for that <lockowner,file>?)

The intent of the seqid is to provide at-most-once semantics to solve
the complex scenerios of replay and dropped requests. It should be
possible to cause the seqid to change without the stateid changing,
for example, a request to change the lock state that was denied. But
conversely, you cannot change the stateid without having the seqid
also change.  Another way to look at this is that the client
controls the seqid and the server controls the stateid.  So, the
client making a locking state change request would increment the
stateid to provide at-most-once semantics, the server upon making
the state change would return a new stateid value. The seqid must
be an increasing integer, the stateid could in theory be any
value as it is opaque from the clients perspective.

If there are subtle changes made in recent backoffs, I am sure
Dave and others will correct me.

	-David