问题描述
1）我认为LightSwitch使用乐观并发。 自上次读取记录以来，它如何确定其更新的记录是否已由其他人更新？ 它是否依赖于数据中的时间戳字段？ 是否仅仅
比较每个字段以查看是否有任何更改？
1) I think LightSwitch uses optimistic concurrency. How does it determine if the record it is updating has been updated by someone else since the last time it read the record? Does it rely on a timestamp field in the data? Does it just compare every field to see if anything changed?
2）在lightswitch文档中有一个处理并发冲突的示例，目前尚不清楚实际结果将是"ClientWins"的情况。 我指的是这个网址：
2) In the lightswitch documentation there is an example of handling a concurrency conflict, it isn't clear what the actual result would be in the situation where the "ClientWins". I am referring to this URL:http://msdn.microsoft.com/en-us/library/ff851990.aspx#HandlingConcurrency
我猜测的情景是2人试图更新同一产品的库存单位值 假设股票最初是5，第一个人减去2，所以现在有3个库存。 当第二个人来到
并且看到它不再是5时，"ClientWins"是什么？实际上呢？ 它是否将其股票价值刷新为3，现在减去第二个人的数量（比如2），最终股票价值为1？ 在
第二个人想要减去的情况下，现在会使股票价值为负，如何防止该错误或将错误反馈给用户会发生什么？ 特别是如果这是股票价值的验证条件（它永远不会是负面的）。
The scenario I am guessing would be 2 people trying to update the Units in Stock value for the same product. Let's say the stock was originally 5 and the first person subtracted 2 so that now there are 3 in stock. When the 2nd person comes along and sees it isn't 5 anymore what does "ClientWins" actually do? Does it refresh its stock value to 3 and now subtract what the 2nd person has for a qty (say 2), which leaves the final stock value to be 1? What happens in the case where what the 2nd person wants to subtract would now make the stock value negative, how to prevent that or raise an error back to the user? Especially if that is a validation condition on the stock value (that it is never negative).
谢谢！
推荐答案
关于如何解决并发冲突，指定ClientWins将导致值更新为第二个用户指定的任何值。当在实体上设置属性值时，运行时不记得如何计算值
（正如您在操作的复合中所建议的那样），但只记得结果。
On how concurrency conflicts are resolved, specifying ClientWins would result in the value being updated to whatever the second user specified. When setting property values on the entities, the runtime doesn't remember how the value was calculated (as you were suggesting in the compounding of operations) but only remembers the result.
为了澄清您的场景中的分辨率将如何发生，假设股票中的单位为5，并且两个用户都打开一个查看该值的屏幕。第一个用户将值修改为3并保存。然后第二个用户将值修改为8并保存，但
这会导致并发冲突，因为原始值（5）与服务器值（3）不同。使用您引用的链接中的代码，指定ClientWins会将字段值设置为8.
To clarrify how the resolution in your scenario would occur, let's say the Units in Stock is 5 and both users open a screen that views this value. The first user modifies the value to 3 and saves. Then the second user modifies the value to 8 and saves, but this causes a concurrency conflict because the original value (5) is different from the server value (3). Using the code in the link you referenced, specifying ClientWins will set the field value to 8.
通过创建允许多个实例的屏幕，您实际上可以自己导致并发错误打开（在设计时打开屏幕，检查属性允许多个实例）。然后运行您的应用程序并在屏幕上打开两个
的实例。在第一个屏幕中编辑记录并保存。然后移动到第二个屏幕，编辑同一个实体（使用不同的值编辑它），然后保存。然后，您将获得并发对话框，以显示原始值，
服务器值和本地值的概念。
You can actually cause a concurrency error yourself by creating a screen that allows for more than one instance to be opened (open the screen at design time, check the property Allow Multiple Instances). Then run your application and open two instances of the screen. Edit a record in the first screen and save. Then move to the second screen, edit the same entity (edit it with a different value), and save. Then you'll get the concurrency dialog to show which will demonstrate the concept of original value, server value, and local value.
这篇关于并发解决问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！