在经典ASP中为自定义数据库构建连接池 [英] Building connection pool for a custom database in classic ASP
问题描述
在我的实际应用程序中，我有一个从经典ASP页面调用的VB6 DLL。该应用程序调用非标准数据库。
In my real application, I have a VB6 DLL which is called from classic ASP pages. The application calls a non-standard database.
我想拥有一个永久保持活跃的连接池类。我设置了编译标志，以便将 DLL 保留在内存中，但尽管如此，池也会被定期销毁。
I want to have a connection pool class which will stay alive permenantly. I set the compilation flags to keep the DLL in memory but despite that, the pool is periodically destroyed.
I我们已经尝试过更改ASP会话超时和每个处理器的线程数，但都不起作用。
I’ve already tried changing the ASP session timeout and the number of threads per processor, neither work.
前一位受访者告诉我，ODBC可以为我处理池行为，但这在这个项目中没有用，因为我必须通过一些定制的数据库对象与数据库进行通信。
A previous respondent has told me ODBC can handle pool behavior for me, but that’s of no use in this project as I have to communicate with the database via some bespoke database objects.
<%
set obj1 = server.CreateObject("LukeTestProj.TestClass2")
obj1.TestA
% >
应用程序片段
MainFn .bas
Option Explicit
Dim x As TerminateDetect
Sub Main()
LogMessage "main called" ‘simple write to file function
Set x = New TerminateDetect
End Sub
TestClass2.cls
Option Explicit
Public Sub TestA()
LogMessage "TestA"
End Sub
Public Sub TestB()
LogMessage "TestB"
End Sub
Private Sub Class_Initialize()
LogMessage "TestClass2 init"
End Sub
Private Sub Class_Terminate()
LogMessage "TestClass2 terminate"
End Sub
TerminateDetect.cls
Option Explicit
Private Sub Class_Initialize()
LogMessage "Initialise called"
End Sub
Private Sub Class_Terminate()
LogMessage "Terminate called"
End Sub
示例日志文件包含
25/12/2009 18:03:07：>>>主叫 - 106369.578
25/12/2009 18:03:07：>>>初始化被叫 - 106369.578
25/12/2009 18:03:07：>>> TestClass2 init - 106369.578
25/12/2009 18:03:07：>>> TestA - 106369.578
25/12/2009 18:03:07：>>> TestClass2终止 - 106369.578
25/12/2009 18:38:04：>>>主要被叫 - 108467.261
25/12/2009 18:38:04：>>>初始化叫 - 108467.276
25/12/2009 18:38:04：>>> TestClass2 init - 108467.276
25/12/2009 18:38:04：>>> TestA - 108467.276
25/12/2009 18:38:04：>>> TestClass2终止 - 108467.276
25/12/2009 18:03:07: >>> main called - 106369.578
25/12/2009 18:03:07: >>> Initialise called - 106369.578
25/12/2009 18:03:07: >>> TestClass2 init - 106369.578
25/12/2009 18:03:07: >>> TestA - 106369.578
25/12/2009 18:03:07: >>> TestClass2 terminate - 106369.578
25/12/2009 18:38:04: >>> main called - 108467.261
25/12/2009 18:38:04: >>> Initialise called - 108467.276
25/12/2009 18:38:04: >>> TestClass2 init - 108467.276
25/12/2009 18:38:04: >>> TestA - 108467.276
25/12/2009 18:38:04: >>> TestClass2 terminate - 108467.276
请注意， main（）被调用两次，但前提是它们之间的空闲时间非常长。永远不会调用 TerminateDetect 类的 Terminate 方法。
Note that main() is called twice, but only if there’s a very long idle period in between. The Terminate method of the TerminateDetect class is never called.
DLL发生了什么？如果这个架构不起作用，我该如何建立连接池？
What’s happening to the DLL? If this architecture won’t work, how can I build a connection pool?
推荐答案
这是一个经典的测试问题。您将修改ASP会话超时，但您很可能已将整个应用程序池空闲超时留在20分钟。您需要打开运行应用程序的应用程序池属性并延长空闲超时。
This is a classic testing gotcha. You will have modified the ASP Session timeout but you most likely have left the overall application pool idle timeout at 20 minutes. You need to open the application pool properties in which you application runs and extend the idle timeout.
您可能希望将ASP会话超时返回到其原始值而不是你真正打算修改的价值。它不是单个会话的生命周期，您希望延长其应用程序的生命周期，即使您想要延长空闲时间。你甚至可能在现实世界中质疑它。
You probably will want to return the ASP session timeout to its original value its not the value you really intended to modify. Its not lifetime of an individual session you want to prolong its the life time of an application even though idle that you want to prolong. You might even question that in the real world.
这篇关于在经典ASP中为自定义数据库构建连接池的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
