read-while-write note
Project: http://git-wip-us.apache.org/repos/asf/trafficserver/repo Commit: http://git-wip-us.apache.org/repos/asf/trafficserver/commit/696f91e2 Tree: http://git-wip-us.apache.org/repos/asf/trafficserver/tree/696f91e2 Diff: http://git-wip-us.apache.org/repos/asf/trafficserver/diff/696f91e2 Branch: refs/heads/master Commit: 696f91e2efd346a7fafebf840d23d44fee82c8f0 Parents: 65ba149 Author: Miles Libbey <[email protected]> Authored: Wed Feb 26 15:10:47 2014 -0800 Committer: Miles Libbey <[email protected]> Committed: Wed Feb 26 15:17:11 2014 -0800 ---------------------------------------------------------------------- doc/arch/cache/cache-arch.en.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) ---------------------------------------------------------------------- http://git-wip-us.apache.org/repos/asf/trafficserver/blob/696f91e2/doc/arch/cache/cache-arch.en.rst ---------------------------------------------------------------------- diff --git a/doc/arch/cache/cache-arch.en.rst b/doc/arch/cache/cache-arch.en.rst index 44b5a75..e0513c5 100644 --- a/doc/arch/cache/cache-arch.en.rst +++ b/doc/arch/cache/cache-arch.en.rst @@ -589,7 +589,7 @@ Cache read starts after a successful `cache lookup`_. At this point the first `` .. sidebar:: Read while write - There is provision in the code to support "read while write", that is serving an object from cache in one transaction while it is being written in another. It is unclear to me if this actually works. It must specifically enabled in :file:`records.config` and if not, a cache read will fail if the object is currently be written or updated. + There is provision in the code to support "read while write", that is serving an object from cache in one transaction while it is being written in another. Several settings are needed for it to be used. See :ref:`reducing-origin-server-requests-avoiding-the-thundering-herd`. It must specifically enabled in :file:`records.config` and if not, a cache read will fail if the object is currently be written or updated. At this point an alternate for the object is selected. This is done by comparing the client request to the stored response headers, but it can be controlled by a plugin using ``TS_HTTP_ALT_SELECT_HOOK``. @@ -599,7 +599,7 @@ Most of this work is done in:: HttpTransact::what_is_document_freshness -First the TTL (time to live) value which can be set in:file:`cache.config` is checked if the request matches the configuration file line. This is done based on when the object was placed in cache, not on any data in the headers. +First the TTL (time to live) value which can be set in :file:`cache.config` is checked if the request matches the configuration file line. This is done based on when the object was placed in cache, not on any data in the headers. Next an internal flag ("needs-revalidate-once") is checked if the :file:`cache.config` value "revalidate-after" is not set, and if set the object is marked "stale".
