控制多用户 Web 应用程序 gridview 中的并发

发布于 2024-09-08 01:27:08 字数 180 浏览 2 评论 0原文

伙计们,我有一个大问题。

我正在运行一个后台应用程序,想象一下,我有一个包含可编辑网格视图的表单。

  1. 100 个用户进入页面
  2. 100 个用户查看表单页面,数据库提供的数据
  3. 100 个用户编辑一些字段
  4. 本例中如何控制最终的数据和一致性?

Guys i'm with a big problem.

I'm running a backoffice application, and imagine, i have a form than contains a gridview editable.

  1. 100 Users go to the page
  2. 100 Users view the form page as the data provided from database
  3. 100 Users edit some fields
  4. How control the final data and consistency in this example?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

最单纯的乌龟 2024-09-15 01:27:08

在您可以计划和实施技术解决方案之前,即。代码,你需要设计整体解决方案。

换句话说,假设您向 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.

绝影如岚 2024-09-15 01:27:08

取决于你真正想要什么。你有要求吗?您在寻求建议吗?

一种可能的解决方案

如果您有一个在编辑完成时调用的显式保存操作,

  1. 用户导航到页面,
  2. 用户修改表,
  3. 用户“保存”,
  4. 页面从数据存储中检索当前值(截至保存)
  5. 页面将当前值与修改值进行比较
  6. 任何冲突都会突出显示,并请求用户“解决”冲突
  7. 转到步骤 3。直到没有检测到冲突

另一种可能的解决方案

如果您想避免该步骤 3。对于步骤 7. 循环,您始终可以将步骤 4. 到 6. 包含在一个事务中,这意味着每次尝试保存,直到当前保存得到解决。这是相当繁重的,需要更多的工作,并且可能会有效地降低整体并发性。

另一种可能的解决方案

另一种可能的解决方案是减少流程的离散性并提高流程的连续性。提供实时数据。

  1. 创建一个 WindowsService/WCF 服务,推送或允许轮询表数据,
  2. Page 轮询数据或从远程服务异步接收数据,
  3. Page 用接收到的数据修改用户的页面内容
  4. 不冲突的新值暂时以一种颜色突出显示(表示冲突) -自由更改),例如浅绿色
  5. 发生冲突的新值将永久以红色突出显示

如果您有保存过程,则在解决之前不会保存红色值。

最后(建议)可能的解决方案

如果您没有明确的保存操作,

  1. 用户单击单元格(有效地请求编辑单元格)
  2. 页面与 Windows\WCF 服务通信,请求“锁定”该单元格,
  3. 如果没有其他用户请求对该特定单元格进行“锁定”,则将单元格锁定到该用户并返回 true。如果另一个用户请求锁定该特定单元格,则尊重当前锁定并返回 false。

如果远程服务返回 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,

  1. User navigates to page,
  2. User modifies table,
  3. User "saves",
  4. Page retrieves current values from datastore (as of time of save)
  5. Page compares current values to modified values
  6. Any conflicts are highlighted and requests user "resolve" the conflict
  7. Goto step 3. until there are no conflicts detected

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.

  1. Create a WindowsService/WCF Service that pushes or allows polling of table data,
  2. Page polls for data or asynchronously receives data from remote service,
  3. Page modifies user's page contents with received data
  4. New values that do not conflict are temporarily highlighted in one colour (indicating conflict-free change), say light green
  5. New values that do conflict are permanently highlighted in red

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,

  1. User clicks on a cell (effectively requesting to edit a cell)
  2. Page communicates to Windows\WCF service requesting a "lock" on that cell,
  3. If no other user has requested a "lock" on that particular cell, then lock cell to that user and return true. If another user has requested lock on that particular cell, then respect current lock and return false.

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.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文