matt wrote:
The coder for the file system makes the choice whether to keep a
snapshot of the data to be read per FID, this way the FID reader will
always get the file they asked for, which, after the first read, isn't
necessarily the current version or to just return whatever each Tread
asks for regardless of whether the underlying data has changed.
It is akin to an SQL cursor. When I make an SQL request the rows
returned are a snapshot of the data when the query was made. If I read
them at one row per second there's a chance that the actual data in the
datastore changes between reads.
Hi,
Although I was not immediately convinced that a versioning approach was
all that useful, I can now see that it roughly matches what I've always
done for servicing web requests for dynamically generated data: each
connection keeps a version, which may or may not be out of date, which
problem is left up to the client to deal with. I guess the difference was
that buffering each version in the web context has always been so natural.
All the "state" (connection, user, object being referenced, cached data)
was kept separately for the entire lifetime of the connection/transaction
and I did not have to worry about anything. I could even timeout the
transaction easily. In the versioning case I would have to 1) store the
different versions somewhere (local fs or memory), 2) track their
association with the related fids, 3) and remove them on clunk. And I
would have to keep the version around until the clunk which might happen
in 1s, 10 minutes, or never.
Either way there's a "tough luck" aspect, if you have a solution I'm
sure everyone would be delighted to hear it :)
It's a perinnial problem. When opening a file for writing some programs
(acme for instance) will warn you if the file has changed since you
opened it. That's a solution to the same problem.
From people's experience, do the following seem like reasonable
alternatives, if the situation allows for it?
1) return an error message if the message size is too small to return
the content in one response? The application would simply trap for
the error condition and retry.
2) if, over the course of returning the individual messages for a read,
an error message was returned which indicated a changed file (the
read operation would no longer return data)? Again, the application
would simply trap for the error condition and retry. This is
something like what editors do (acme, as you mention), except that
the read operation is affected rather than trying to prevent an
overwrite of possibly newer data.
I guess I am trying to avoid versioning because there are too many
aspects that I am concerned I could not reasonably deal with. I'd
like to be able to support something akin to an atomic transaction
(although it would involve multiple reads/messages).
Any comments on a third option?
3) if versioning is used, reads would only be supported on a cached
version for a limited period of time. Afterwards, the cached
version would be dropped and an error message would be returned
indicating something like "File version has expired."
I realize that this none of these may be general solutions but
for specific kinds of data (e.g., status information) they may be.
And, the client accessing the files would have to be prepared to
deal with the different kinds of error messages. The goal is to
get correct/consistent data.
Thanks for everyone's input,
John
