Transient storage location? database/xcache/w3Total Cache?

I’ve been working to speed up my site by utilizing transients to store rendered HTML and it works great. I’ve set up checks that clear specific transients upon post/page/data updates and it all works well. I’ve got some complex db checks, so it really speeds things up.

But I’m hitting a stumbling block on coming up with an overall management of the transients. For instance, if I change the theme templates I’d like to be able to delete multiple transients so that they will be automagically regenerated. In a few instances, I have only five different transients, so it’s easy to loop through them. But in other snippets, I have over 100 variations.

At a base level, transients may be stored in the database and these are easy to search and find, even using wildcard searches. However, they aren’t always stored in the database. But where are they stored? I utilize the xcache php opcode cacher, but I don’t seem them in the xcache variable listing. I use W3 Total Cache as well, but even with object caching turned off (or the plugin disabled), I can’t seem to figure out where they are stored.

My thought is that instead of trying to delete each transient individually (which always works fine), I’d like to be able to do wildcard searches for them such as “myprefix_” and then delete all that match. With the db, I can do that…and there are a lot of examples of that here. But I can’t figure out where the transients are…if they aren’t in the database..and I don’t see them in the xcache admin.

Thanks for any insights..

In general you don’t work with storage in the case of transients. You work with Transients API which makes use of either database or Object Cache.

Object Cache implementations are arbitrary, it can make use of any back end out there anyone bothers to make work.

So effectively there is no way to bulk delete transients since there is no bulk delete in underlying Object Cache (some back ends just won’t be able to perform such operation).

For a public solution you would have to engineer your caching logic in a way that functions within these constraints.

One of the common techniques is including some sort of identifier in transient keys, so that changing identifier effectively makes “old” set inaccessible. Take note of key length limitations though.