GAE更新同一实体的不同字段
UserA 和 UserB 分别同时更改 objectA.filedA objectA.filedB。 因为它们没有改变同一领域,所以人们可能会认为没有重叠。 这是真的吗? 或者 pm.makePersistnace() 的实现实际上覆盖了整个对象...... 很高兴知道...
UserA and UserB are changing objectA.filedA objectA.filedB respectively and at the same time.
Because they are not changing the same field one might think that there are no overlaps.
Is that true?
or the implementation of pm.makePersistnace() actually override the whole object...
good to know...
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
这是你想象中发生的事情吗?
Bob 的对象副本将覆盖数据存储中的副本,因为他保留了他的整个对象,而不仅仅是他的一组已更改的字段。或者,一般来说,无论哪一个最后保留,其整个对象都会保留在数据存储中。
您可以通过在事务中运行每个 get-set-and-persist 操作来解决此问题。 App Engine 事务不会锁定整个对象以防止在本地检索或修改,它们只是阻止其他用户保留。所以:
我不确定哪个用户会收到异常,但只要他们愿意在看到异常时重试,他们都可以做出更改对象并最终持久化它们。
这称为乐观锁定。
Is this what you're envisioning happening?
Bob's copy of the object will overwrite the copy in the datastore, because he's persisting his whole object, not just his set of changed fields. Or, in general, whichever of them persists last has their whole object persisted in the datastore.
You could fix this by running each of their get-set-and-persist operations in a transaction. App Engine transactions don't lock the whole object from being retrieved or modified locally, they just prevent other users from persisting. So:
I'm not absolutely sure which user will get the exception, but as long as they're willing to retry when they see it, they'll both be able to make their changes to the object and persist them, eventually.
This is called Optimistic Locking.
感谢您的回答。
遗憾的是 makePersistence() 实现是将整个对象写入数据存储区,而不仅仅是写入已更改的字段。
这一事实实际上迫使 GAE 中的任何共享对象更新都使用事务作为规则。
此外,在这种情况下,您必须实现“重试机制”,因为事务中可能会发生异常。
所以...更新 GAE 中的任何共享对象应该始终具有这些额外功能:
Google 网站中的大多数示例实际上都没有考虑到这一点。就好像他们假设大多数应用程序不会使用共享对象
例如(http://code.google.com/appengine/docs/java/datastore/creatinggettinganddeletingdata.html):
或者:
Thanks for your answer.
Pity that the makePersistence() implementation is to write the WHOLE object to the datastore and not only to the fields that were changed.
This fact is actually forcing ANY shared object update in GAE to use a transaction as a rule.
Further more - in such cases you must implement the "retry mechanism" as an exception in the transaction may occur.
So... updating any shared object in GAE should ALWAYS have these extras:
Most of Google's examples in their site are actually not taking that into account. As if they're assuming that most apps won't used shared objects
For example (http://code.google.com/appengine/docs/java/datastore/creatinggettinganddeletingdata.html):
OR: