.NET Remoting线程锁定机制

发布于 2024-08-19 02:20:43 字数 562 浏览 8 评论 0 原文

我有一个紧迫的问题,希望大家能帮助我。我会尽力解释它。

我正在增强一个使用 .NET 远程处理的系统,以允许从瘦客户端到执行所述调用的服务器进行数据库调用。服务器本身安装了数据访问组件,因此它对数据库进行实际调用,并且仅将数据行返回给瘦客户端。

我最近刚刚向这些模块添加了交易。我想让这个线程安全,如果客户端线程 A 启动数据库事务,客户端线程 B 将无法访问客户端线程 A 的事务。同时不必允许客户端线程B拥有自己的事务,只需要我不允许客户端线程B使用客户端线程A的事务即可。

只有 1 个对它们共享的远程处理对象的引用,并且由于我不会深入了解底层架构,因此我无法更改它。所有事务对象都存储在服务器上的此远程处理对象中。

除了可能将客户端线程信息与每个事务调用一起传递之外,我看不出有什么好的方法可以做到这一点,这对于我紧迫的时间表来说是不可行的。 :-( 也许如果远程对象可以访问调用客户端线程,那么我就不必在每次调用时传递线程信息,从而使这变得可行。

如果有某种方法将客户端线程与远程处理线程关联起来,我我认为这可以解决问题,但我没有找到关于这样的事情的文档,

我希望我能很好地解释这一点,非常感谢您的帮助。

I'm having a pressing issue and I'm hoping you all can help me out. I will try my best to explain it as well as I can.

I am augmenting a system that uses .NET remoting to allow for database calls from a thin client to a server that executes said calls. The server itself has the data access components installed on it, so it makes the actual calls to the database, and just returns the datarows to the thin client.

I just recently added transactions to these modules. I wanted to make this thread-safe, where if client thread A started a database transaction, client thread B would not be able to access client thread A's transaction. It is not necessary to allow client thread B to have it's own transaction in the meanwhile, only necessary that I do not allow client thread B to use client thread A's transaction.

There is only 1 reference to the remoting object that both of them share, and because of the underlying architecture that I will not get into, I am not able to change this. All of the Transaction objects are stored on the server in this remoting object.

I see no good way of doing this, besides perhaps passing the client thread information along with every single transaction call, which is not feasible with my pressing timelines. :-( Perhaps if the remoting object could access the calling client thread, then I would not have to pass the thread information with every call, making this feasible.

If there was some way of associating a client thread with a remoting process thread, I think that would do the trick, but there is no documentation that I could find on such a thing.

I hope I explained this well enough. All help is greatly appreciated. Thank you in advance.

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

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

发布评论

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

评论(2

始于初秋 2024-08-26 02:20:43

我不是 100% 确定是否可以做到这一点,但使用 CallContext 可能会有所帮助。简而言之,CallContext 是可以远程连接到服务器的带外数据,请参阅此博客 此处 为例。如果您不明白带外 (oob) 是什么,请查看此处< /a> 在维基百科上。这是另一个具体示例此处。这可能会给你线索。

I am not 100% sure if this can be done, but using the CallContext may help. In a nutshell, a CallContext is an Out-Of-Band data that can be remoted across to the server, see this blog here for an example. If you do not understand what an Out-Of-Band (oob) is, look here on wikipedia. Here's another concrete example here. That may give you the clue.

神仙妹妹 2024-08-26 02:20:43

你想要做的事情听起来有点奇怪,所以让我看看我是否理解:

  • 你在服务器端使用单例,这就是为什么每个客户端在服务器上只有 1 个线程。

  • 假设交易过程需要很长时间(秒到分钟),其他客户端必须等待,直到第一个客户端完成。

    假设

我认为但我不确定每个客户端的调用都在创建它自己的线程。如果这是真的,那么当远程对象需要进行线程安全调用时,只需实现一些“锁定”调用就可以解决问题。锁定的成本很高,如果事务需要几秒钟,那么等待的其他人可能会超时(哎呀!)

这就是 TransactionScope 对象构建的类型 (参见 MSDN)。如果不了解更多有关解决方案的框架,我就无法真正提供帮助。

抱歉...我不知道这是否有用。

What you're trying to do sounds kinda weird so let me see if I understand:

  • You're using a singleton on the server side this is why each client has only 1 thread on the server.

  • Assuming that the transaction process takes a long time (seconds to minutes) the other clients MUST wait until the first client has finished.

I think but I'm not sure that each client's call is creating it's own thread. If this is true then simply implementing some "lock" calls when the remote object needs to make thread safe calls should do the trick. Locking is expensive and if the transaction is taking seconds then the other guy waiting might timeout (eeK!)

This is the kind of stuff that the TransactionScope object was built for (See MSDN). I can't really assist anymore without knowing more about the arch of the solution.

Sorry... I don't know if this is useful or not.

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