On Apr 12, 2010, at 4:31 PM, Andrew Deason wrote: > To alleviate this, we've been thinking about allowing reads to occur on > a ubik database even when there's a conflicting write lock. When the db > is write-locked, we know that the data is consistent, since no actual > changes occur until the commit. So, a site would allow reads until a > write transaction was committed, and reads would be blocked while we > commit the changes to the local db. > > The problem with doing this is that it allows different data to be > visible from the ubik db at the same time to clients (some sites could > have committed data, while others are waiting for a commit and are > serving old data). Is that horrible? Will that break everything?
Off the top of the head this doesn't seem to be a significant problem. Data changes all the time, and different clients will get different data depending on when they ask. When that data goes out of date, the current clients seem to recover well. The second suggestion about returning error codes would seem to require a lot of mods to the clients. Steve_______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
