.dll or .exe ??

[rjlohan]

What is the most appropriate for a component that will be used by a set of ASPs to access a database?

[AngelinaM]

Dll, make sure you destroy it after you are finished using it.

set object = nothing

[rjlohan]

Hehe - had that problem yesterday. The .dll throws an error, doesn't get destroyed by the asp, and hence I can't bloody update it, because the OS says it's in use...

[simonm]

Perhaps it is a problem with you dll...do you have a memory leak?

[rjlohan]

No it's OK. Someone has solved this for me. The IIS still holds onto it in a cache or something, to reduce reload time apparently.

I have to stop/start IIS through control panel to release it.


Cheers,
RJ


P.S - Don't see much of you in the tech forums Simon.

[deja]

hi,
do u store your com object (dll) in Application or Session object?

[rjlohan]

Application I guess - I just create and destroy it as needed.

[deja]

what do u mean u 'guess'?
when u craete object how u doing it?
where u create the object? in global.asa or in specific page?

[rjlohan]

I mean 'I guess' because I'm not fully aware of the difference...

I create it on a specific page. I know it's not a Session object, so if there's only one other choice, I guess I must be using application objects.

[deja]

hi,
if u create your object per page it's fine.
it means that u do not put it in Application or Session object.
there r 2 possible ways to create object per page.
the first is to add object tag in the page, and the second through Server.CreateObject function.
the difference between the 2 is that in the first one, ASP create the object only when u make a call to the object explicitly. in the second case ASP create the object when he encounter the line with Server.CreateObject even if u do not making any use of that object at the next code.
another thing is, never put an ActiveX DLL that created in VB in Application or Session object due to threading problem.

[rjlohan]

What's the threading problem? I have since starting this thread decided I want the object at Session level, as I want it to maintain some information for that scope.

But as I have a .dll what problem will I encounter? I haven't had any that I'm aware of during testing?

[deja]

hi again,
this is a bit complex, do u want me to explain it?

[rjlohan]

Yes please. I'm up to it.

[deja]

every process running in the win32 system must have at least one thread of execution.
the main thread act as an entry point to the process and is responsible for creating the main window (in case of user interface

application) and set up a message loop to monitor incoming messages from the operating system.
each process can have more than one thread, in this case it called multi thread application.
in multithread application each thread have it's own stack. the schedular (part of the system responsible to control the threads in the

system) allocate processing cycles by giving each thread a time slice.
the problem in this manner is that u don't have control on the schedular that give time slice arbitrary. this mean that the schedular can
take control off the thread in a middle of computing some values.
this can lead to serious problems like inconsistency in data or even data corruption.
For example, suppose we have an application with two threads. thread A calculate values and produce a new value to global variable

called Sum. now at the middle of the computation, the system passes control to thread B which need the new value of Sum. but the

value of Sum is incorrect because thread A didn't finish his work on that variable. this situation can lead (in the worse case) to crash

the process.
the problem with global data that accessed by multiple threads known as concurrency.
in languages like c/c++, there r tools to handle with this situations. like semaphores, mutex and more.
to avoid these problems with concurrency, it's possible to local varibles on the call stack for each thread. VB make heavy use of this

TLS (thread locla storage) technique.
as you can see, concurrency makes an application vulnerable to data inconsistency.

the apertment model in COM is an abstraction concept, intended for concurrency problems.

do u want me to continue?

[rjlohan]

Ok yep, I understand all that. However, I'm still not clear on why having the .dll in a Session/App variable will be any more of a problem than if it's in a single page.

And in any case, I don't think I'll have too much problem, the only global data being accessed by multiple instances of this .dll is a database, and they only read the data, so there shouldn't be any trouble there.

[deja]

hi,
i didn't finish yet, it was just a preface to understand the problem.
i will write latter.

[rjlohan]

You got the rest of this one available yet?

[deja]

hi,
i'm sorry, i totally forgor about it.
look, right down is a link to understand what i have started, if u still have problems post me a message and i'll do my best to complete my explanation.
http://codeguru.earthweb.com/activex...artments1.html

[rjlohan]

Cheers.