[Webkit-unassigned] [Bug 22700] ApplicationCache should have size limit

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=22700





------- Comment #6 from andreip at google.com  2009-04-29 11:33 PDT -------
Thanks Michael,

(In reply to comment #5)
> Some drive-by comments and questions...
> 
> * What happens if a cacheGroup that is in the act of being updated gets
> evicted? Maybe those not be subject to eviction?
> 

It seems that an update will simply create a new cache and set it as the
"newest cache" for the group, while the old cache is obsoleted. If the update
fails due to maximum size being reached, the insertion of this newest cache is
rolled back. It could happen that, while trying to make some room for this new
cache, the relevant group is wiped out. However, in such a case, it will simply
be re-added once the insertion of the new cache is retried after the cache
eviction is completed.

> * What precautions prevent the particular cache group that is being updated (or
> added to) and causing the need to evict something from being evicted itself?
> 

If I understand the existing code right, adding a new cache group is an atomic
operation. If it turns out that there isn't enough room for it, then all
operations will be rolled back. When the eviction routine kicks in, it will not
find this new cache group. As for updating and existing cache group, please see
my answer above. I could be missing some edge case, though...

> * The eviction logic examines 'caches' and decides which to boot, maybe this
> should look at 'cacheGroups' instead.
> 

Erm, why would that be better than looking at the caches?

> * I'm not sure if a partially updated caches are left around (after the network
> connection drops midway thru) and the update picks up where it left off upon
> the next attempt. If so, these partial updates could be the first to go without
> having to blow away the associated group altogether.
> 

As said above I don't think this is possible (unless I am missing something).
The entire cache seems to be downloaded first and then saved, so you'll never
have a partially updated cache in the database.

> * Maybe the decision making about which cacheGroups to evict should be left to
> a delegate api provided by the embedding browser? The system currently has no
> way of determining which groups are more or less important (outside of LRU). I
> could see that being value added by host browsers.
> 

It could. However, the chromeclient (i.e. embedding browser) currently doesn't
know when an application is being cached. I therefore don't know if it makes
sense to ask it about which applications should be evicted either.

I've also uploaded a new patch as I found a couple of problems with my last
one:
- I wasn't updating EmptyClients.h so the build would break if SVG is enabled.
- the "PRAGMA page_count" was added only in SQLite 3.6.0 so in older versions
getting the current size of the database that way will fail.

I'd be grateful if you could have another look.

Thanks,
Andrei


-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.