Problem/Motivation
With a non-DB backed cache, updating nodes can result in stale data being in the cache due to a race condition.
This is because when an entity is saved we open a new DB transaction, during which we do all the updates to the data tables, and we clear the relevant items in the cache tables, at the end of the saving process the transaction is committed and all of those operations happen as one atomic piece.
If however, your cache backend is not the DB, then the cache flush will happen immediately, allowing a window for another operation to come in and cause the flushed cache items to be rebuilt from the non-updated DB source data, because the transaction hasn't been committed yet.
Proposed resolution
Many options. I think that we're still at the stage of getting to consensus on the issue.
Remaining tasks
Obtain consensus on a sensible way to resolve this, and then code that up.
I'm not sure that this is testable? Can we test race conditions?
User interface changes
None.
API changes
None at the moment.
Original report by @slashrsm
There can be a race condition when using some other cache back-end than DB (Memcached in my case). Data will be saved in DB at the end of function since node_save() uses db_transaction(). Field cache is, on the other hand, cleared at field_attach_update().
If there comes a request to the node being saved just after the field cache was cleared and before the transaction was commited we end up with a outdated data in field cache.
This will happen only if some other cache back-end than DB is used. Field cache will be cleared when transaction is commited, so there should be no problem in this case.
Related issues:
#1658672: It seems as sometimes empty and old nodes are served by memcache
#1677830: Node not saved when hook_node_insert() or hook_node_update() are invoked
And some more background about this issue:
http://janezurevc.name/strange-behaviour-race-condition-during-nodesave