您如何处理/响应 GUI 层上的用户输入并发性？
处理用户输入并发的好方法是什么？
由于这个问题的答案已经排除了数据库锁定，那么如何做您通常处理并发用户输入吗？
锁定总是一个坏主意，即使它不是通过行锁定实现的？ 是否存在不依赖于用例的最佳实践？ 您的策略有何经验？
编辑：我知道通过事务处理数据级别的并发性：如果两个用户同时触发复杂的数据更改，事务将处理它。
但我有兴趣在 GUI 层处理它们或至少对其做出反应。 如果数据更改是与用户交互的冗长操作的一部分怎么办？
假设两个或更多用户正在通过 Web 界面编辑同一个文件。 在某个时刻，其中一位用户点击了保存按钮。 其他用户会发生什么情况？
- 他们会收到通知和/或被迫重新加载吗？ 或者最终会覆盖第一个用户的更改？
- 我应该锁定文件并防止多个用户编辑同一个文件吗？
- 我可以将整个编辑过程放在一个事务中（我非常怀疑，但谁知道......）
处理这种情况和类似情况的最佳方法是什么？ 还有其他策略吗？
What are good ways to handle user input concurrency?
As the answers to this question already rule out database locking, how do you handle concurrent user inputs in general?
Is locking always a bad idea, even if it is not implemented by row locking? Are there best practices which are not use case dependant?
What were your experiences with your strategies?
EDIT: I'm aware of handling concurrency on a data level through transactions: If two users simultanteously trigger a complex data change, transaction will handle it.
But I'm interested in handling or at least reacting to them on the GUI layer. What if the data change is part of a lengthy operation with user interaction?
Let's say two or more users are editing the same file over a web interface. At some point one of the users hits the save button. What happes to the other users?
- Will they get notified and/or forced to reload? Or will the eventually overwrite the changes of the first user?
- Shall I lock the file and prevent multiple users editing the same file?
- Can I put the whole editing process in a transaction (I highly doubt it, but who knows...)
What is the best way to handle this and similar situations? Are there any other strategies?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
最佳策略取决于从（业务）流程的角度来看应该发生什么 - 同样重要的问题是用户通常期望什么以及最不让他们感到惊讶的是什么，当然，实施他们的内容是否可行预计。
您通过网络编辑文件的示例可以细分如下：
out/gets/downloads/opens 文件 v0
out/gets/downloads/opens file v0
文件 v0
文件 v0
注意，这对于 Web 应用程序来说是典型的，实际上对于普通的桌面办公程序也是如此，用户所做的最新更改仅在之后才可用（对其他人）保存它们，这意味着在您正在编辑的文件副本中，同事的输入不会出现在您的输入之上。
对此的经典版本控制方法是，对于用户 1 而言，与正常的桌面编辑/保存过程相比，没有任何变化。
然而，对于 user2，当他尝试将 v2 保存到服务器时，应用程序必须检查自用户上次下载以来文件版本 v0 是否有任何更改。 在这种情况下，版本控制系统通常会在屏幕上并排显示两个版本（v1 和 v2），并让他混合它们并将生成的版本（v3）保存到服务器。
对于文本文件，Unix 和 Windows 上都存在许多工具和系统，它们试图使该过程自动化，这样如果编辑的文件区域不重叠，更改就会自动合并。
另一种方法是锁定用户 2 的文件，直到用户 1 完成编辑。
将编辑放入事务中通常是无关紧要的。 这是尝试用新版本覆盖现有文件的最后一个操作，这一点很重要。 编辑在每个用户工作站上独立进行，直到最后一点（保存）才接触服务器。
顺便说一句，您的示例与预订机票或预约看医生等其他情况明显不同。
预订机票时，飞机上的座位数量有限。 由于数据传输实际上并不能让多个人同时预订飞机上同一个最后一个座位，因此这是可能的。
因此，预订过程至少应分为两步：
（s1）；
确实还是免费的，如果是的话，
保留给您。
“确实仍然免费”步骤是因为网页用户浏览量信息通常不会实时更新，因此在步骤1和步骤2之间，可能有其他用户已经申请了免费时段。
Best strategy depends on what should happen from (business) process perspective - also important questions are what users would normally expect and what would surprise them least, and, of course, whether it is feasible to implement what they expect.
Your example of editing a file over web can be broken down as follows:
out/gets/downloads/opens file v0
out/gets/downloads/opens file v0
file v0
file v0
Note, that it is typical for web applications, and indeed for normal desktop office programs, too, that newest changes that user makes only become available (to others) after saving them, which means that it is not a case of having colleague's typing appear on top of yours in the copy of file you are editing.
A classic version control approach to this is that for user1 nothing changes as compared to normal desktop editing/saving process.
For user2, however, when he attempts to save v2 to server, the application must check whether there have been any changes to file version v0 since user last downloaded it. Since this is the case, a version control system would typically show him both versions (v1 and v2) on screen side by side, and let him mix them and save the resulting version (v3) to server.
For text files there exist a number of tools and systems both on Unix and Windows that try to automate the process so that if the areas of file edited do not overlap, the changes are merged automatically.
The alternative is locking file for user2 until user1 has finished editing it.
Putting editing in transaction is typically of no relevance. It is the final operation which attempts to overwrite existing file with new version, that is important. Editing happens independently on each users workstation and does not touch the server until last point (saving).
Your example is, by the way, distinctly different from another situation such as booking airplane tickets or booking an appointment to a doctor.
When booking tickets, there is a limited number of seats in a plane. It is possible, due to the fact that data transfer is not actually instanteous for more than one person to put a reservation to the same last seat on a plane.
Therefore, booking should be at least a 2-step process:
(s1);
is really still free, and if so,
reserves it to you.
The "really still free" step is because information on webpage user views is typically not updated realtime, so between steps 1 and 2, it is possible that another user has applied for the free slot.
寻找如何在您使用的任何语言/数据库 API 中处理“事务”。 如果你正确设计这些，它会为你处理它。
为了理解这个理论，我建议 Couloris 等人的分布式系统，但还有很多其他好书。
Look for how to handle "transactions" in whatever language/database API you are using. If you design these correctly it will handle it for you.
And to understand the theory, I'd recommend Distributed Systems by Couloris et al but there are lots of other good books.