Building connection pool for a custom database in classic ASP

Question

In my real application, I have a VB6 DLL which is called from classic ASP pages. The application calls a non-standard database.

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’ve already tried changing the ASP session timeout and the number of threads per processor, neither work.

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.

ASP Code Snippet

<%
set obj1 = server.CreateObject("LukeTestProj.TestClass2")
obj1.TestA
% >

Application Snippet

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

A sample log file contains

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

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.

Question

What’s happening to the DLL? If this architecture won’t work, how can I build a connection pool?

Answer 1

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.

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.