soft and hard ttl on cache

2,109 views
Skip to first unread message

Anders Aagaard

unread,
Jul 9, 2013, 6:37:47 AM7/9/13
to volley...@googlegroups.com
Hi

I noticed the following code in CacheDispatcher:
                // If it is completely expired, just send it to the network.
                if (entry.isExpired()) {
                    request.addMarker("cache-hit-expired");
                    request.setCacheEntry(entry);
                    mNetworkQueue.put(request);
                    continue;
                }

                // We have a cache hit; parse its data for delivery back to the request.
                request.addMarker("cache-hit");
                Response<?> response = request.parseNetworkResponse(
                        new NetworkResponse(entry.data, entry.responseHeaders));
                request.addMarker("cache-hit-parsed");

                if (!entry.refreshNeeded()) {
                    // Completely unexpired cache hit. Just deliver the response.
                    mDelivery.postResponse(request, response);
                } else {
                    // Soft-expired cache hit. We can deliver the cached response,
                    // but we need to also send the request to the network for
                    // refreshing.
                    request.addMarker("cache-hit-refresh-needed");

But refreshNeeded and isExpired is exactly the same code. As ttl and softtl is set to the same value by HttpHeaderParser.

If I understand this right one can never get to cache-hit-refresh-needed without overriding something and writing to the cache ttl/softttl manually. How is this intended to be used?

Best regards
Anders

Ficus Kirkpatrick

unread,
Jul 9, 2013, 10:57:53 AM7/9/13
to Anders Aagaard, volley...@googlegroups.com
refreshNeeded() and isExpired() are not exactly the same. One compares to the ttl value and the other to softTtl. This can be used to implement request semantics where you will return a response from cache even if it is "soft" expired, but will then go to the network and refresh, returning a new response if the data has changed.

I generally don't recommend using this unless you really, really know what you're doing because handling the second response can be pretty tricky to get right. And you need to implement a custom Request to use it anyhow.


Anders

--
You received this message because you are subscribed to the Google Groups "Volley Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to volley-users...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

Reply all
Reply to author
Forward
0 new messages