Getting a stale snapshot of the view should be very easy.Until you commit the transaction, you can just get the current node.
On Sat, Nov 8, 2008 at 5:53 PM, Chris Anderson <[EMAIL PROTECTED]> wrote: > On Fri, Nov 7, 2008 at 11:06 PM, Ayende Rahien <[EMAIL PROTECTED]> wrote: > > I want to be able to get a response in a limited amount of time.Even if > that > > response is optionally stale (marked by a header?) > > > > This would be ideal. The hard part here is getting access to a stale > view representation from disk. I'm not sure you can get a btree root > from the disk, that is known to be consistent, unless it just came > from the updater process. Maybe it'd be simple enough to do... but in > any case, it's not really the feature that this patch is working on, > although the patch does lay the groundwork for these more complex view > query modes. > > Damien maybe you can chime in about getting consistent but stale view > indexes from the disk? > > > The absolute worse thing to happen is to have a request just wait for 5 > > minutes before timing out or returning a result. > > That ties up resources across the entire network > > Once again, I think it really is the site operator's responsibility to > keep any user-facing views up to a certain degree of readiness. In > some cases, a quick error may be better than waiting 5 seconds (or 5 > minutes) for a view to generate. But in other cases, we'd send the > error instead of generating the view, and then turn out to have the > view generate in less than a second. There's no way to know ahead of > time how long it will take to update a view. Luckily, keeping your > views up to date makes all these problems go away. > > Chris > > > -- > Chris Anderson > http://jchris.mfdz.com >
