WebRequest 服务与本地数据库搜索

发布于 2024-11-05 08:32:28 字数 424 浏览 1 评论 0原文

我有一个运行多个线程的应用程序,其中该过程的一部分涉及向 Web 服务发出 http post 请求,在数据库中检查我提交的参数是否已存在,如果不存在则插入。

数据库本身托管在应用程序运行的同一服务器上。我们最初将其托管在不同的服务器上,但它崩溃了,硬件故障......并且无法处理我每秒发出的所有请求。

现在,我在向服务发出请求时遇到服务器错误,并且想知道哪种方法更有效、更快...并且更不容易出错...

  1. 使用向服务发出请求的现有方法并解决问题或
  2. 访问我自己在本地数据库并检查表并自己进行插入,这显然会减慢进程

我试图避免这里的问题,设置服务的程序员说他已经完成了他的所有工作,我应该间隔我的请求更多,但我仍然不明白为什么突然出现主键违规错误在移动之前,如果我发送表中已存在的参数,我将收到设置的响应,而不是内部服务器错误。

I have an application that runs multiple threads where a part of the process involves making http post requests to a webservice where the parameters I submit are checked in a database whether it exists already and if not then inserted.

The database itself is hosted on the same server where the app runs. We originally had it hosted on a different server but it crashed, hardware failure..and was not able to handle all the requests I make per second.

Now I am getting server errors when making requests to the service and was wondering which approach would be more efficient and faster...and less error prone...

  1. use the existing method of making requests to the service and work around the issue or
  2. access the db locally myself and check the tables and do the inserts myself which will obviously slow down the process

I am trying to avoid issues here and the programmer that set up the service says he has done everything on his part and I should space out my requests more but I still do not see why all of a sudden I am getting primary key violation errors when prior to the move, if I sent a parameter that already exists in the table I would receive a set response and not an internal server error.

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

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

发布评论

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

评论(1

别低头,皇冠会掉 2024-11-12 08:32:29

Web 服务请求是异步的,因此您将无法解释 PK 违规错误。有多种方法可以处理这种情况:

  1. 应该更改 Web 服务托管代码以处理这样的情况:当 PK 存在时,它应该返回与第一次发送请求时给出的相同响应。调用请求是单独的,并且在单独的线程上,并且永远不会知道另一个请求已经插入了相同的值。 WS 的全部意义在于,多个请求可以从任何地方同时传入。业务逻辑应该处理它们同时进入的情况。

  2. 更改您的代码以直接访问数据库(正如您所提到的)。无论如何,这不会使过程变慢(尽管需要提前更改代码),因为 WS 请求必须通过 HTTP 协议,而从您的代码中,您将通过代码提供的 ADO 或 OLEDB 提供程序直接访问.

  3. 您可以将请求排队,然后逐个处理,直到处理收到响应后才处理下一个请求。我不喜欢这个,因为它不可扩展 - 违背了 WS 的目的(但如果程序员不更改 WS 代码,您可能会陷入困境)

WS 编码器建议的解决方案是荒谬的。无法将您的请求间隔开,以免导致 PK 违规。您无法知道哪些请求已被插入,或者哪些其他请求已在处理中。此外,间隔请求并不会使整个应用程序具有可扩展性 - 您的前端(或其他正在等待响应的组件)最终将处于等待状态。

Webservice requests are asynchronous, so you will not be able to account for the PK violation errors. There are various ways to handle the situation:

  1. The webservice hosting code should be changed to handle the situation that when a PK exists, it should return the same response it gave when the first time that request was sent. The calling requests are separate, and on separate threads, and would never know that another request already inserted the same value. The whole point of WS is so that multiple requests can come in at the same time, from anywhere. The business logic should handle that they come in at the same time.

  2. Change your code to access the DB directly (as you mentioned). This will not make the process slower by any means (although work is involved upfront to change your code), since a WS request has to go over HTTP protocol, whereas from your code you will access directly via ADO or OLEDB provider that your code provides.

  3. You could possibly queue up your requests, and then hit one by one, and not hit the next one until the one processing has received a response. I don't like this because its not scalable - defeats the purpose of a WS (but you may be stuck with this if the programmer doesn't change the WS code)

The solution suggested by the WS coder is ridiculous. There is no way to space out your requests so that it won't cause the PK violation. There is no way you can know which ones have already been inserted, or what other requests are already in process. Also, spacing out requests doesn't make the whole application scalable - your front end (or whatever else is waiting for the response) will end up waiting.

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