控制多用户 Web 应用程序 gridview 中的并发
伙计们,我有一个大问题。
我正在运行一个后台应用程序,想象一下,我有一个包含可编辑网格视图的表单。
- 100 个用户进入页面
- 100 个用户查看表单页面,数据库提供的数据
- 100 个用户编辑一些字段
- 本例中如何控制最终的数据和一致性?
Guys i'm with a big problem.
I'm running a backoffice application, and imagine, i have a form than contains a gridview editable.
- 100 Users go to the page
- 100 Users view the form page as the data provided from database
- 100 Users edit some fields
- How control the final data and consistency in this example?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
在您可以计划和实施技术解决方案之前,即。代码,你需要设计整体解决方案。
换句话说,假设您向 100 个不同的人分发了 100 张纸,每个人都附有该网络表单的副本。这 100 个人在纸上写下笔记,然后以随机顺序将其交还给你。
在这种情况下你如何处理一致性?当你能回答这个问题时,你就可以实施它。
然而,如果不了解更多有关该表格中的数据的信息,实际上不可能为您提供具体的建议。
Before you can plan and implement the technical solution to this, ie. the code, you need to design the overall solution.
In other words, consider that you handed out 100 pieces of paper to 100 different people, each with a copy of that web-form on it. Those 100 people scribble notes on their paper, and then hand it back to you, in a random order.
How do you handle consistency in this scenario? When you can answer that, you can implement it.
Without knowing more about the data you have in that form, it will be practically impossible to give you concrete advice however.
取决于你真正想要什么。你有要求吗?您在寻求建议吗?
一种可能的解决方案
如果您有一个在编辑完成时调用的显式保存操作,
另一种可能的解决方案
如果您想避免该步骤 3。对于步骤 7. 循环,您始终可以将步骤 4. 到 6. 包含在一个事务中,这意味着每次尝试保存块,直到当前保存得到解决。这是相当繁重的,需要更多的工作,并且可能会有效地降低整体并发性。
另一种可能的解决方案
另一种可能的解决方案是减少流程的离散性并提高流程的连续性。提供实时数据。
如果您有保存过程,则在解决之前不会保存红色值。
最后(建议)可能的解决方案
如果您没有明确的保存操作,
如果远程服务返回 false,则用例结束,并且无法修改单元格。如果远程服务返回 true,则用户修改内容,当他们离开单元格或重新加载页面或其他任何操作时,远程服务会释放锁定。
结论
好吧,有点挥手,但脂肪足以咀嚼。想一想,有很多可能的解决方案。
Depends on what you want really. Do you have requirements? Are you fishing for suggestions?
One possible solution
If you have an explicit save action that is invoked when editing is complete,
Another possible solution
If you want to avoid that step 3. to step 7. loop, you could always wrap steps 4. through 6. in a transaction, meaning every other attempt to save blocks until current save is resolved. This is pretty heavy handed and requires a bit more work and may effectively reduce overall concurrency.
Yet another possible solution
Another possible solution is to make the process less discrete and more continuous. Provide a live feed of data.
If you have a save process, no red values may be saved until resolved.
Last (suggested) possible solution
If you have no explicit save action,
If remote service returns false, then use-case ends, and cell cannot be modified. If remote service returns true, then user modifies contents and when they leave the cell or reloads page or whatever, the remote service releases the lock.
Conclusion
Alright, a bit of hand waving, but more than enough fat to chew. Give it some thought, there are many possible solutions.