Hi Rick,

I was under the impression that virtually all of the so called "global" storage used by an instance of a MTDLL is (by necessity) allocated to the thread as thread-local storage. Thus once ASP initiates a thread (which it may keep around for however long it deems is appropriate based on load), that thread is granted its own (as it sees it) global storage, but this memory is thread-local in terms of memory management. As long as the thread exists, that TLS is essentially static storage, but it's only really "global" for _that_ thread. Public memory variables, open-table metadata, and environment metadata (e.g., the "SET" setting) thus are all persistent entities but only within the context of just that thread. It's not until ASP terminates the thread does that "global" storage and the settings within it actually go away.

To me, its like having multiple instances of VFP.EXE open on a PC. I'm a user coming to sit at my PC, and at random the PC pops one instance into the foreground to use. That instance has its own "global" storage that none of the other instances can see. Unless I have been the only user of all instances of VFP.EXE that have been opened on that PC, then I can make no assumptions about which tables might already be open, what the "SET" setting might be, etc. In the ASP/MTDLL world, my ASP app might indeed be the only user of a MTDLL that I wrote for some very specific purposes, thus I would have apriori awareness of what settings might already be in place. For example, if one table is open, then I might be able to safely assume that other tables are also open if in fact the only place in code where one table is opened is a code segment where I actually open several at once.


>Hi Christof,
>
>It's been a while since I've looked at this madness <g>...
>
>Yes, you're right - I forgot that ASP holds the DLL captive on a thread. But it's really unreliable because there an instance of the DLL tied to each thread in ASP.
>
>If you run your test from a couple of separate browser instances (ASP does something with Keep alives and trying to tie the client to the same thread if load is light) you'll see that from time to time the tables are forced open again. I take this to mean that a new thread is firing up and a new instance of the VFP runtime is getting bound to it.
>
>You can see that happening if you ammend the code with:
>
>FUNCTION TableTest
>
>IF !USED("WebCounters")
> USE WebCounters IN 0
> RETURN "Table openeded..." + TRANSFORM(Application.ThreadId)
>ENDIF
>
>SELECT WebCounters
>RETURN "Table already open..." + TRANSFORM(Application.ThreadId)
>
>ENDFUNC
>
>and you'll see the thread number bounce around. As long as the thread was previously hit the table is already open. Hit a new thread and the table is opened again. So each instance of VFP is managed per thread.
>
>Of course if you use a Session object things always open and close which is unfortunately the default recommendation Microsoft makes <g>.
>
>+++ Rick ---
>
>>Hi Rick,
>>
>>>No, this isn't right... Tables close when the object is destroyed in all
>>>situations. Even if you're not using a Session object.
>>
>>I guess my comparison to a desktop application wasn't the best one <g> COM objects are created in an instance of VFP. This instance is bound to the lifetime of all objects instantiated in that instance. If the last object is destroyed, the instance is shut down and all tables are closed. As long as there's one object still alive, the instance remains loaded and tables stay open.
>>
>>>Try this in an MTDLL:
>>
>>Compiled it to test.test. What I meant is the following. Even though o1 is released in between, the table remains open because o2 keeps the instance in memory.
>>

>>o1 = CreateObject("test.test")
>>? o1.TableTest()
>>o2 = CreateObject("test.test")
>>o1 = null
>>o1 = CreateObject("test.test")
>>? o1.TableTest()
>>

>>Of course, this is a simplified scenario, because VFP as a host doesn't load the MTDLL into multiple threads or does weird things with caching DLLs as ASP does.
>>
>>>Well, the point is moot since tables can't stay open across calls. There's no point in closing tables if you're using MTDLLs from ASP/ASP.NET since they don't persist.
>>
>>What are you doing differently than I am? I copied the test.dll created from your code into \inetpub\scripts and registered it. I also created a webcounters.dbf file in \Windows\System32, because that's where DLL tries to open the file. Then I create the following test.ASP:
>>

>><%
>>  Set oRef = createobject("test.test")
>>  Response.Write( oRef.TableTest() )
>>  Set oRef = Nothing
>>
>>

>>The first time I call the page I get "Opened table". Then I hit F5 and get "Table already open". This is on Windows XP SP2 with ASP being pretty much in the default configuration.
>>