ASP.NET和长时间运行的后台线程 - 他们怎么混？ [英] ASP.NET and long running background threads - how do they mix?
问题描述
在我写我需要使用连接到特定服务器一个ASP.NET应用程序（像一个数据库，但...不同）。连接是建立相当昂贵（几秒钟，字面意思）所以我想写一个池，以提高可伸缩性。
In a ASP.NET application that I am writing I need to use connections to a specific server (something like a DB but... different). The connections are quite expensive to establish (a few seconds, literally) so I'm trying to write a pool to improve scalability.
一切是pretty简单，到一个点 - 回收旧连接。在旧我的意思是已在池中未使用比，也就是说，5分钟再连接。清洁起来也将腾出资源，他们连接到服务器上。
Everything is pretty simple, up to one point - recycling old connections. With old I mean "connections that have been in the pool unused for longer than, say, 5 minutes". Cleaning them up would also free up resources on the server that they connect to.
我需要某种形式的线程唤醒每隔5分钟，检查在池老未使用的连接，并关闭它们。但是，正如我来自谷歌，ASP.NET和长时间运行的线程明白不要混用。
I would need some kind of thread that wakes up every 5 minutes, checks for old unused connections in the pool, and closes them. However, as I've come to understand from Google, ASP.NET and long-running threads don't mix.
我不害怕的全过程被终止，因为那样的话我会池得到清理过（析构函数和所有）。我很害怕的是，我的应用程序终止前（和我的池也就没有了清洁）我清除线程可能会被终止。或者反过来 - 我清洗的线程块我的应用程序从结束
I'm not afraid of the whole process being terminated, because then my pool would get cleaned up too (destructors and all). What I am afraid of is that my cleanup thread might be terminated before my application terminates (and my pool is left without a cleaner). Or the other way round - that my cleaning thread blocks my application from closing.
如何正确执行呢？
一些人建议的外部服务将做到这一点。我将详细阐述了mysterios服务，让你可以看到为什么这是不可行的。
How to implement this correctly?
Several people have suggested an external service that would do this. I will elaborate on the "mysterios service" so that you can see why this is not feasible.
神秘的服务是已超过10年写的我公司的应用程序的庞然大物。它是使用MSSQL或Oracle其数据的德尔福会计应用程序。有没有其他的服务器。
The "mysterious service" is a behemoth of an application that has been written by my company for over 10 years. It is a Delphi accounting application that uses MSSQL or Oracle for its data. There is no other server.
最近（如在几年前），也获得了外部应用程序可以使用与它进行通信的接口。它是Windows控制台应用程序，基本上是相同的应用程序，除了没有GUI它监听套接字，并使用某种德尔福序列化到来回传递数据。
Recently (as in a few years ago) it also acquired an interface that external applications can use to communicate with it. It is windows console application that is basically the same application, except instead of GUI it listens to a socket and uses some kind of Delphi serialization to pass data forth and back.
在客户端有一个.DLL（用Java编写的，后来修改下J＃编译），它解析这个二进制数据流，并在mimicks .NET业务层。那就是 - 我得到的所有相同的业务类（700），如在Delphi原来的应用程序。什么pretty接近（我认为应用程序本身有> 3000类）。而我必须用他们做我想要的任何业务逻辑。我的所有来电被转发到真正的应用，然后做的工作。
On the client side there is a .DLL (written in Java, later modified to compile under J#) which parses this binary data stream and mimicks the business layer in .NET. That is - I get all the same business classes (700+) as in the original application in Delphi. Or something pretty close to that (I think the application itself has >3000 classes). And I have to use them to do whatever business logic I want. All my calls get forwarded to the real application which then does the work.
我不能直接连接MSSQL / Oracle数据库，因为在服务器中，我将不得不复制并跟上（应用程序正在不断地被开发）很多企业的bizzare逻辑。我不能重新创建客户端.DLL，因为那将是太费时，协议将规定反正几乎相同的结果。我不会写它周围的包装，因为我会换所有的700类，都在那里。
I cannot connect directly to the MSSQL/Oracle DB, because there is a lot of bizzare business logic in the server that I would then have to replicate and keep up with (the application is constantly being developed). I cannot recreate the client .DLL, because that would be too time-consuming, and the protocol would dictate nearly the same result anyway. I cannot write a wrapper around it, since I would have to wrap all the 700+ classes that are in there.
在其他的话 - 我不是在业务层的控制权。这是因为它是（实际上几个人已经退出，而不是继续使用它）。我只是想做出最好的东西。
克里斯和其他好奇的人。
In other words - I'm not in control of the business layer. It is as it is (and actually several people have quit rather than continue working with it). I'm just trying to make the best of things.
To Chris and other curious people.
在code使用的东西是这样的：
The code to use the stuff is something like this:
ConnectionType con = new ConnectionType;
con.OpenConnection("server", "port", "username", "password");
BLObjectNumber234 obj = (BLObjectNumber234)con.GetBLObject("BLObjectNumber234");
obj.GetByPK(123);
// Do some stuff with obj's properties and methods
// that are different for each BLObject type
这些BL对象是pretty杂乱无章。他们都是单身 - 以 con.GetBLObject 调用总是返回相同的实例。大部分数据是通过调用一个特殊的方法获得一个数据表，但不少也在性能;有些需要调用带有无证的bizzare常量特殊的方法;也有是BL行吟诗人对象实例（不知道这些是否单身过，我不这么认为）的属性和那些需要特殊的code来填充等。
These BL objects are pretty haphazard. They are all singletons - The call to con.GetBLObject always returns the same instance. Most of the data is obtained as a DataTable by calling a special method, but quite a few are also in properties; some require calling special methods with bizzare undocumented constants; there are also properties that are othe BL object instances (not sure whether those are singletons too, I think not) and those require special code to populate, etc.
所有的一切，我会调用系统patchware - 因为看起来它已经由一百万制作的补丁和解决办法都以任何方式曾经最方便的时候粘在一起。
磕碰？ （你怎么办呢碰撞在这里吗？）
All in all, I'd call the system "patchware" - since it seems like it has been made by a million patches and workarounds all sticked together in whatever way had been most convenient at the time.
Bump? (how do you do bumping here anyway?)
推荐答案
您不需要为包装每一个类和功能，只是你需要执行的操作。所以，你可能需要获取一些数据，并更新一些数据的方法的方法，这将视需要在服务的一系列调用各种功能的转换。前端逻辑将被简化，因此，这将简化网站的未来版本
You would not need to wrapper every class and function, just the actions that you need to perform. So you might need a method to fetch some data and a method to update some data, this would translate in the service as a series of calls to the various functions as required. The front-end logic would be simplified and therefore this would simplify future releases of the web site.
好吧，只是为了满足自己除了这个问题 - 我觉得你越来越喜欢挂在包装的含义。我希望，你已经做了某种wrappering反正，也许我需要停下来假设这并要求您的问题直接：你直接从asp.net页面背后的code调用这个服务，还是有你建立单独的类来处理前端和服务之间的沟通？一旦我们建立的架构，你现在有我们将看到是否可行这个逻辑移动到一个单独的服务（并从中获益的WCF能够提供）。
Ok, just to address your own addition to this question - I think you are getting too hung up on the meaning of "wrapper". I would hope that you are already doing some sort of wrappering anyway, or perhaps I need to stop assuming this and ask you the question directly: Are you calling this service directly from the code behind the asp.net pages, or have you built separate classes to handle the communication between the front end and the service? Once we establish the architecture you currently have we will see whether it is feasible to move this logic to a separate service (and then reap the benefits that WCF can offer).
这篇关于ASP.NET和长时间运行的后台线程 - 他们怎么混？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
