Persisting an object in application scope

[Karu]

Hi! I have a kind of application dictionary in XML format, and I need to access it in all pages of my ASP application. I thought that it could be a good idea to create an instance of a DOM object and load the xml file in the Application_OnStart event, so I have the instance available anytime I need it during the application execution.
What kind of troubles could I find doing something like that?

Thanks in advance!

Karu

[john_k]

Storing a COM object in the Application object will lock your application down to one thread.

[Easy_Coder]

Have you implemented a template approach to your application?

If you have then you could create your object in your opening template and shut it down in your closing template.

<!--#include file="TopTemplate.asp"-->
Page Content Here...
<!--#include file="BottomTemplate.asp"-->

TopTemplate.asp would include something like:

Set oXMLDict = Server.CreateObject("MyXML.Dictionary")

Then load your dictionary...

BottomTemplate.asp would shut it down

Set oXMLDict = Nothing

[Karu]

Thanks for all the information.
I guess I'll have to figure out other kind of solution because my application already has almost 500 pages.
Thank you anyway!

Regards,

Karu

[Karu]

Hi! I've recently found that exist a class FreeThreadedDOMDocument30 in the Msxml3.dll
Can I use it to avoid the lock down problem?

Thanks again!

Karu

[plumsauce]

you might want to try this sequence:

1/ load xml object at application start
2/ extract xml as a string
3/ store resulting string as an application variable
4/ free xml object

in your pages,

1/ create xml object
2/ load xml string into object from application variable
3/ extract what you want
4/ free object

[raywood]

I do it the way plumsauce suggests. But I ran into trouble with multiple threads. I created an additional application variable to lock the xml file each time any code tried to access it. Every code block in any thread that wants the xml file, checks the locking variable first. If the file is locked by some other thread, it sleeps and tries again until the first thread unlocks it by resetting the variable.

This was neccessary becasuse various threads modify the xml file. For a static file that does not get changed, it's probably not needed.

[Karu]

Thanks for your help. I don't understand very well what's the difference between loading a xml file and loading a xml string each time, is one much faster than the other?.
I don't need to update the file.
I've read that you can store an object at application scope if the COM is free-threaded (or multi-threaded), that's why I've asked about FreeThreadedDOMDocument class.
Have you ever used it? Do you know if it solves the problem?

Regards,

Karu

[john_k]

I don't understand very well what's the difference between loading a xml file and loading a xml string each time, is one much faster than the other?.

First, the two options that had been previously mentioned were to store the xml OBJECT or store the xml as a string. You can't really store a file in RAM (it is only file contents, which is the same as the xml string).

So, I am guessing that you really want to know the difference between storing the xml dom object and storing the xml as a string. The difference is that storing the object will lock the application down to a single thread (unless it is multi-threaded). Storing the string won't.

I've read that you can store an object at application scope if the COM is free-threaded (or multi-threaded), that's why I've asked about FreeThreadedDOMDocument class.
Have you ever used it? Do you know if it solves the problem?

I am fairly certain that what you read is correct. Do you have a link to the article?

Here is a related link in the MS KB concerning apartment-model threading. I am pretty sure that the bit about being locked to a single thread comes from here. Btw - this encompasses any VB6 DLLs.

[Karu]

I was talking about loading the file or the string INTO the xml object.
Here is one of the links I've read --> [hanselman.com...]

Thanks again for all your help!

Karu

[danieljean]

The mind boggles... I often wish I had the ease of use of .Net for some stuff, and then I read a thread like this.

Damn, am I ever glad I'm working with J2EE!

Not trying to start a flamewar... but are you guys sure there isn't a better way than reload the object with every call? That seems like a massive performance hazard; parsing XML into DOM is fairly heavy.