There are two collections in the Application object in Classic ASP:
Application.StaticObjects, filled in<object>sections inglobal.asaApplication.Contents, filled by whatever code decides to store something there, including<script>sections inglobal.asa
I note one apparent disadvantage of the StaticObjects collection: You cannot initialize objects you store. Let’s take the example of an XML document. You can store a free-threaded DOM object there, but how if you wanted to preload an XML file? I cannot see a way to achieve this.
Does StaticObjects have any advantage to compensate for this disadvantage?
More generally, how are these collections different with regard to things like concurrency or access or whatnot?
The discussion below has shown that there actually is an advantage to using <object> and hence Application.StaticObjects, and that is lazy evaluation. But then, of course, lazy evaluation is something you can easily code yourself (and with greater flexibility) in a script. Still, for application-scoped singletons to be created on demand, the <object> tag can be useful.
I’ve never come across any need or advantage to use
<object>in the Global.asa as opposed to simply usingContentsin theOnStartevent.Apart from the way objects end up being instanced and placed in these collections there is no real difference betweent them. Objects need to be free-threaded and thread-safe.
My advice would to just ignore
StaticObjectsand work with simple code.