数据存储：删除事务以外的实体 [英] datastore: deleting entities outside transactions

问题描述

我无法找到完全解释从数据存储中删除实体（我正在使用JDO deletePersistent）而不在事务中的文档。我可以在并行更新期间保证数据的准确性，因为为了性能和避免争用而不使用事务。但是，如何确保代码在不同的时间运行在同一时间，一个 delete 操作不会被稍后的 update / put 在前一次读取到另一台机器上的该实体时重写，我让PersistenceManager采取注意对附加对象的隐式更新。

编辑：
尝试更新该实体后deletePersistent将导致一个异常，但是当试图更新确切将相同的副本传递给deletePersistent。但是如果它是另一台计算机上的另一个副本，则会被视为更新已删除的实体（无效）或作为插入或更新导致将该实体退回？

解决方案

答案是肯定的，即使在对象被删除之前，如果它之前被读取并且更新在删除之后被提交承诺它将被退回，因为@Nick Johnson评论插入和更新是相同的。测试了在获取更新对象后使用20秒线程休眠，从而允许删除对象并将其放回。

I'm unable to find documentation that fully explains entities being deleted from datastore (I'm using JDO deletePersistent) without being in a transaction. I can afford loosing data accuracy during parallel updates when not using transaction for the sake of performance and avoiding contention.

But how can i make sure when my code is running on different machines at the same time that a delete operation would not be overridden by a later update / put on a previous read to that entity on another machine, I'm letting PersistenceManager take care of implicit updates to attached objects.

EDIT: Trying to update that entity after deletePersistent will result in an exception but that is when trying to update the exact same copy being passed to deletePersistent. but if it was a different copy on another machine would be treated as updating a deleted entity (not valid) or as an insert or update resulting in putting that entity back?

解决方案

The answer is yes, even after the object was deleted if it was read before and the update was being committed after delete was committed it will be put back because as @Nick Johnson commented inserts and updates are the same. tested that using 20 seconds thread sleep after getting object for update allowing the object to be deleted and then being put back.

这篇关于数据存储：删除事务以外的实体的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！