support tag invalidation with Symfony HttpCache

[dbu]

#237 separated tagging from BAN. we can now support tag invalidation with the symfony cache without needing full BAN support (#148).

/cc @andrerom

[andrerom]

Any opinion on how?
As I might have mentioned before I was thinking of using hardlinks, or better yet as it is supported by Symfony FileSystem component: symlinks. So place symlinks in a tags structure pointing to the actual cache, and place meta info on all tags in the cache item itself or a meta item next to it. Hence possibility for lookup by tag for tag invalidation, and by item like today for serving the response and url invalidation.

But surly other ways to archive it as well.

[dbu]

i like the idea of the links. i think @dantleech was also thinking about how to solve this, maybe he has further inputs?

[dantleech]

Would there not be a problem in having multiple pages/caches for one tag if we took the symlnks approach? Off the top of my head I think I would just have a folder with tag files:

tags/my-tag-1
tags/my-tag-2

where the tag file had a list of the cache files which have that tag, so it becomes a many-to-many relationship. Or have I misunderstood?

[dbu]

hm. with files, there are race conditions, or the need for locks. maybe a folder tags/<my-tag-1>/symlink ? so one folder per tag with symlinks to all cache entries? (and both writing new tags and invalidating must be able to cope with dangling links if the cache was deleted for some reason already) also, symlinks probably won't work on some windows machines, not too sure.

[dantleech]

Maybe we could have a strategy and implement both approaches?

[andrerom]

Afaik on Windows there are mainly issues with symlinks when user is lacking rights, ref:

if (!$ok && true !== @symlink($originDir, $targetDir)) {
    $report = error_get_last();
    if (is_array($report)) {
        if ('\\' === DIRECTORY_SEPARATOR && false !== strpos($report['message'], 'error code(1314)')) {
            throw new IOException('Unable to create symlink due to error code 1314: \'A required privilege is not held by the client\'. Do you have the required Administrator-rights?', 0, null, $targetDir);
        }
    }
    throw new IOException(sprintf('Failed to create symbolic link from "%s" to "%s".', $originDir, $targetDir), 0, null, $targetDir);
}

[dantleech]

fyi, I have started an experiment: https://github.com/dantleech/tagged-symfony-cache

This version is middleware. It uses the symlinks approach and I think the invalidation can be handled locally instead of what it currently does with a HTTP request.

[dbu]

cool! is your idea to contribute that into FOSHttpCache or would it be a library on its own? there is an edge case which "locally", if you have either other systems that detect they need to invalidate cache, or if you have multi server setup. but i could live with that limitation - if you do a multi-server system or other massive system, you should use varnish rather than the symfony built-in cache anyways.

[andrerom]

There is nothing stopping anyone using a cache lib as alternative Symfony HttpCache backend in the future. But should probably pick a lib that is already supporting tagging when you/they do.

[dantleech]

At the moment it is just an experiment, something I am going to test on my website.

I will make a PR here when I have something reasonable and we can discuss the approach and decide where it belongs.

[dantleech]

ok, its up and running on my webserver http://www.dantleech.com

I have added a readme to the library: https://github.com/dantleech/tagged-symfony-cache

[dbu]

cool. the only reason to inject the TagManager into the AppKernel is to make it available in the container, right? that is the part of not using HTTP but in process calls to invalidate? having the tag as middleware seems like a good idea. but its inconsistent with the trait we provide in FOSHttpCache to make AppCache use events... how would you feel about using the events instead?

[dantleech]

On Fri, Nov 27, 2015 at 07:38:23AM -0800, David Buchmann wrote:

cool. the only reason to inject the TagManager into the AppKernel is to
make it available in the container, right? that is the part of not using
HTTP but in process calls to invalidate?

Exactly -- alternatives are including an invalidate header in the
response or invalidation with an "inline" Request (which will not work
on the single-threaded PHP built-in webserver I found out).

Including the header in the response might not always work if for some
reason something else returns a response earlier, or replaces the
response.

Invalidation with a new request would be fine when using a
multi-threaded webserver.

But I think injecting the TagManager is a good and stable solution for
simple applications, at the cost of some kernel modification.

having the tag as middleware seems like a good idea. but its
inconsistent with the trait we provide in FOSHttpCache to make AppCache
use events... how would you feel about using the events instead?

Working on a PR now.

—
Reply to this email directly or [1]view it on GitHub.

Reverse link: [2]unknown

References

Visible links

1. support tag invalidation with Symfony HttpCache #251 (comment)
2. support tag invalidation with Symfony HttpCache #251 (comment)