Flushing object cache removes all transients

[deploysk]

Flushing the object cache by calling wp_cache_flush() removes all stored transients.

Description
Transients are often used by plugins to store results of performance expensive tasks. Transients do have an expiration date and usually are closely managed by plugins to only invalidate when necessary.

When object cache is active, WordPress saves all transients in object cache only.

Object cache is often flushed by plugins on routine tasks as updating posts (e.g. WooCommerce products).
This also removes all stored transients.

This often results in huge performance setbacks as all transients need to get re-built, even though they did not reach their expiration date.

One example is WordPress saving the results of the last check for updates for all plugins as a site transient. Loading the current version from an external source for tens of plugins can take several seconds and is only performed once per day.
However, if users update any WooCommerce products on this site, cache gets flushed along with all transients. WordPress will now load the current versions again. If the page contents are updated regularly during the day, the site will make perform this expensive task over and over again, ultimately beating the main purpose of an object cache, making the page load slower.

Expected Behavior
There should be better expiry management in place for transients to not remove all of them during each object cache flush.

Actual Behavior
All transients are deleted when flushing the object cache.

Steps to Reproduce

1. Activate an object cache solution (e.g. Redis Object Cache).
2. Create any transients by loading the page.
3. Modify contents to trigger cache flush (e.g. update a WooCommerce product).
4. Verify, if the transients were removed (e.g. by counting them with redis-cli --scan --pattern "wp:transient:*" | wc -l)

[flixos90]

@deploysk Thank you for reporting this, and welcome to Trac.

After considering the ticket, I am not sure it makes sense for WordPress Core, for the following reasons:

• Transients are caches, just like other data in object cache. From that perspective, I don't see why flushing the cache shouldn't flush transients too.
• The benefit of transients is that they also work on sites without an object cache.
• A wp_cache_flush() call by its name implies that caches are cleared. So it does not sound right to me to leave transients in place when this function is called.
• Even if we wanted to implement it, technical limitations may make it tricky or even impossible. It would require a mechanism that deletes all object cache groups except the transient groups. The alternative would be to store transients in the database always, but that is a no-go for big sites where the database for transients could lead to performance issues.

Would like to hear other people's feedback, but I'm leaning towards closing.

[joemcgill]

I agree with @flixos90. The other thing to keep in mind is that transients were given their name due to the fact that they cannot always be expected to exist in the database.

​Quoting rmccue from the Transient API docs:

Everyone seems to misunderstand how transient expiration works, so the long and short of it is: transient expiration times are a maximum time. There is no minimum age. Transients might disappear one second after you set them, or 24 hours, but they will never be around after the expiration time.

If you have a feature that depends on the data always existing, it is better to store that data as an option, rather than as a transient.