[OpenAFS-devel] ubik write-locks, commits, reads

[Steve Simmons]

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.
>=20
> 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=