Concurrent entity loading and saving might result in false cache entries under circumstances

Created on 7 September 2016, about 8 years ago
Updated 4 June 2024, 3 months ago

Problem/Motivation

First a brief overview of our case:
1. We have a lot of entities of a custom entity type.
2. We have a view, which displays some of the properties of each entity in a single row. The view itself is tags-based cached.
3. This page has a really high access frequency rate.
4. Additionally we have a drush command, which is executed each minute once. This drush command triggers a service, which might change some of the entites and save them with a new revision, even create a couple of revisions at once. Currently this process takes up to couple of seconds.

Now here is what we've observed:
1. An entity which is shown on the view has been saved with the changed timestamp 1473263761, which is the REQUEST_TIME of the execution of the drush command, which is not equal to time().
2. The cache entry for the views field of this entity has a created timestamp 1473263765.398, which is estimated with microtime(). You might say 4 seconds after the entity has been saved, but this would not be correct, as the entity changed timestamp is set through REQUEST_TIME and the service might need a couple of seconds to come to the point of saving the entity.
3. The entity was originally in revision 20.
4. The drush command created revisions 21 and 22.
5. On the views page we are still seeing the entity in the revision 20, for which the new views field cache entry has been created instead for the revision 22.

I think this is not a problem with views but with the cache system.

I could not explain how this exactly happens but I guess this should be reproducible.

Proposed resolution

none.
Possibly resolved by these issues. See #25

Remaining tasks

Confirm this is still a problem.
Find a way to reproduce it.

User interface changes

none.

API changes

none.

Data model changes

none.

πŸ› Bug report
Status

Closed: cannot reproduce

Version

11.0 πŸ”₯

Component
CacheΒ  β†’

Last updated 1 day ago

Created by

πŸ‡©πŸ‡ͺGermany hchonov πŸ‡ͺπŸ‡ΊπŸ‡©πŸ‡ͺπŸ‡§πŸ‡¬

Live updates comments and jobs are added and updated live.
  • Needs issue summary update

    Issue summaries save everyone time if they are kept up-to-date. See Update issue summary task instructions.

Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • The Needs Review Queue Bot β†’ tested this issue. It either no longer applies to Drupal core, or fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

    Apart from a re-roll or rebase, this issue may need more work to address feedback in the issue or MR comments. To progress an issue, incorporate this feedback as part of the process of updating the issue. This helps other contributors to know what is outstanding.

    Consult the Drupal Contributor Guide β†’ to find step-by-step guides for working with issues.

  • πŸ‡¦πŸ‡ΊAustralia larowlan πŸ‡¦πŸ‡ΊπŸ.au GMT+10

    Would be good to get an issue summary update here

  • Status changed to Postponed: needs info over 1 year ago
  • πŸ‡³πŸ‡ΏNew Zealand quietone New Zealand

    I checked with larowlan in #bugsmash and as a result I am changing this to get more information.

    There hasn't been discussion here for 6 years, so maybe this has been resolved?

    @hchonov, is this still a problem? If not, what did you do to resolve it? If not, is there a way to provide steps to reproduce?

    Since we need more information to move forward with this issue, I am setting the status to Postponed (maintainer needs more info).

    Thanks!

  • πŸ‡¬πŸ‡§United Kingdom catch

    I think this has been resolved in the following three issues:

    https://www.drupal.org/project/redis/issues/3018203 β†’

    https://www.drupal.org/project/drupal/issues/2966607 β†’

    https://www.drupal.org/project/memcache/issues/2996615 πŸ› Transaction support for cache (tags) invalidation Needs review

  • πŸ‡³πŸ‡ΏNew Zealand quietone New Zealand

    @catch, thanks for that

    We now have an indication that this may have been fixed by work done in several issues.

    In order to keep this open we need confirmation that this is still a problem. If you are experiencing this problem on a supported version of Drupal reopen the issue, by setting the status to 'Active', and provide complete steps to reproduce the issue β†’ (starting from "Install Drupal core").

    If we don't receive additional information to help with the issue, it may be closed after three months.

  • Status changed to Closed: cannot reproduce 3 months ago
  • πŸ‡³πŸ‡ΏNew Zealand DanielVeza Brisbane, AU

    We are reviewing this again as part of the Bug Smash Initiative. This has had no updates in over a year and earlier reviews suggest that this has been fixed by other issues, so I'm now marking this issue as closed.

Production build 0.71.5 2024