On 28 mars 2013, at 03:04, Ivan <[email protected]> wrote: > With ATOMIC_REQUESTS, after cache invalidation, the concurrent process can > re-create cache old data, between deleting of cache and commit.
If I understand correctly, you're describing the following scenario. It assumes you have two concurrent process, A and B, that deal with a value X from the database, cached as Y. - Process A opens a transaction (because of ATOMIC_REQUESTS or otherwise) - Process B looks for Y, doesn't find it, reads X - Process A changes X - Process A invalidates Y - Process B caches Y - Process A commits the transaction Now, take the transaction out of the picture, and you still have the same race condition: - Process B looks for Y, doesn't find it, reads X - Process A changes X - Process A invalidates Y - Process B caches Y > Perhaps this problem should be solved by repeat cache deleting after commit. Even if your proposal solved the problem, I would reject it because it introduces tight coupling between the request handler and the cache. The coupling between the request handler and the ORM created by ATOMIC_REQUESTS is bad enough. It would also be quite messy to implement. -- Aymeric. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
