>>>I don't have your huge experience with web apps. Can you explain why it isn't scalable and what other
>>>problems may arise, please?
>>
>>Anything that is loaded as an Application object var is essentially the same as a global var, which means it's shared by all users and pages in a Web site. If you have an object and two pages want to access that object it gets queued. If the object is not free threaded IIS will block all access to any other COM object until the call completes. If it is free threaded it will make the call and add implicit Application.lock/Unlock's around the object access.
>
>Assuming that WSH is free threaded and this global/Application object is never used for anything else than to
>keep the WSH loaded (so, no problem with the simultaneous access): Is it still a bad idea?
>
>>Basically you should avoid Application object use just like you avoid using globals in a VFP application. Use only when absolutely no other way is available to share data.
>
>I understand this as well as that having global vars in a web app that may run on multiple web servers simultaneous is
>a bad idea. But I never intended to use that global object.

I guess I'm not sure what the benefit is. ASP will already do an extra AddRef on any COM object it loads so any associated runtimes will stay loaded in memory anyway. However, there's overhead in loading hte actual binary signature of hte object into memory. This is what I was referring to as the overhead given that WSH is pretty big.

Using the Application object just to cache whatever runtime may be involved really buys nothing. If WSH is free threaded then accessing the object would be faster for a single user than reloading it, but always remember it's a single object that's shared between all of the users. Even with free threading it's shared in this fashion when attached to the application object. THe other alternative is the Object tag in global.asa which can take advantage of free threading pointing at the same COM instance if it is fully thread safe!