1

Summary I have an issue where the database writes from my task queue (approximately 60 tasks, at 10/s) are somehow being overwritten/discarded during a concurrent database read of the same data. I will explain how it works. Each task in the task queue assigns a unique ID to a specific datastore entity of a model. If I run a indexed datastore query on the model and loop through the entities while the task queue is in progress, I would expect that some of the entities will have been operated on by the task queue (ie.. assigned an ID) and others are still yet-to-be effected. Unfortunately what seems to be happening is during the loop through the query, entities that were already operated on (ie.. successfully assigned an ID) are being overwritten or discarded, saying that they were never operated on, even though -according to my logs- they were operated on.

Why is this happening? I need to be able to read the status of my data without affecting the taskqueue write operation in the background. I thought maybe it was a caching issue so I tried enforcing use_cache=False and use_memcache=False on the query, but that did not solve the issue. Any help would be appreciated.

Other interesting notes: If I allow the task queue to complete fully before doing a datastore query, and then do a datastore query, it acts as expected and nothing is overwritten/discarded.

Roy Lindsay
  • 13
  • 2

1 Answers1

1

This is typically an indication that the write operations to the entities are not performed in transactions. Transactions can detect such concurrent write (and read!) operations and re-try them, ensuring that the data remains consistent.

You also need to be aware that queries (if they are not ancestor queries) are eventually consistent, meaning their results are a bit "behind" the actual datastore information (it takes some time from the moment the datastore information is updated until the corresponding indexes that the queries use are updated accordingly). So when processing entities from query results you should also transactionally verify their content. Personally I prefer to make keys_only queries and then obtain the entities via key lookups, which are always consistent (of course, also in transactions if I intend to update the entities and, on reads, if needed).

For example if you query for entities which don't have a unique ID you may get entities which were in fact recently operated on and have an ID. So you should (transactionally) check if the entity actually has an ID and skip its update.

Also make sure you're not updating entities obtained from projection queries - results obtained from such queries may not represent the entire entities, writing them back will wipe out properties not included in the projection.

Dan Cornilescu
  • 39,470
  • 12
  • 57
  • 97
  • Thanks for your response, this works for me, it should be noted that implementing database ancestry was required before I could implement the transaction (read) solution. Without implementing ancestry, my single entity kind was being treated as separate entity groups per entity, raising the entity group limit error. https://stackoverflow.com/questions/8251594/how-many-objects-is-too-many-for-in-a-single-transaction-to-googles-datastore – Roy Lindsay Oct 21 '19 at 04:44
  • Check the API, there's an option to allow cross-group transactions (but watch for the max number of entity groups per transaction limit). Structure your transactions to minimize the number of entities touched inside each of them - to not hit that limit and to reduce the chance of contention (see also https://stackoverflow.com/a/45496048/4495081). For example don't update multiple entities unless they absolutely need to be updated together, not because it's easy to iterate on them. – Dan Cornilescu Oct 21 '19 at 10:48