--On Friday, July 24, 2009 04:45:08 PM +0200 Felix Frank
<[email protected]> wrote:
I see the point, it's not useful if it's only for decoration. It does
feel intuitively right to have txid, if it could be used by a family of
RPCs. Might make for cleaner interfaces for cancellation, abandonment,
(not to mention futures--reversibility, delegation, ...)?
Also note that multiple _reads_ can be going on at once, and you want to
be able to track those, too, so you can avoid letting anyone write while
there's a read in progress.
The fileserver simply assumes that anyone who tries to extend or release
a lock is the caller that actually holds the lock, instead of using a
transaction ID. Let's not make the same mistake here.
I can't see this going wrong.
Yes, and no one could see anything going wrong with the way locks worked,
either. How can you tell that the transaction being ended is the same
transaction that was started, if there's no transaction ID. Remember, just
because _you_ think there's only one outstanding transaction doesn't mean
that some client that started an earlier transaction agrees.
"readers are being counted" doesn't help, if I can claim to you that I'm
done reading when I'm not actually included in your count.
-- Jeffrey T. Hutzelman (N3NHS) <[email protected]>
Carnegie Mellon University - Pittsburgh, PA
_______________________________________________
OpenAFS-devel mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-devel
