How access xml file in a thread-safe manner, using classic asp?

I have an xml file, which is to be updated by an asp script (vbs)
when users are submitting forms from their browsers. Now I wonder if
there is anything that stops the following to occur:

1. User A submits form, resulting in asp script to create
MSXML2.DOMDocument.4.0, which loads the xml file and updates the
in-memory DOM tree
2. User B submits form, roughly at the same time, also resulting in
asp script to create MSXML2.DOMDocument.4.0, which loads the same xml
file and updates its own in-memory DOM tree
3. The thread handling user A saves its updated DOM tree back to disk,
replacing the original file
4. The thread handling user B saves its updated DOM tree back to disk,
replacing the file containing the updates just saved for user A

Is the above something that can happen, using IIS 5 and ASP script?
Of course

If so, would storing a FreeThreadedDOMDocument.4.0 in the Application
variable be a good way to fix this, or are there any better
approaches?

Any help on this would be appreciated, since I am a little lost when
it comes to threading and asp.

Mats Olsson wrote:

I have an xml file, which is to be updated by an asp script (vbs)
when users are submitting forms from their browsers. Now I wonder if
there is anything that stops the following to occur:

1. User A submits form, resulting in asp script to create
MSXML2.DOMDocument.4.0, which loads the xml file and updates the
in-memory DOM tree
2. User B submits form, roughly at the same time, also resulting in
asp script to create MSXML2.DOMDocument.4.0, which loads the same xml
file and updates its own in-memory DOM tree
3. The thread handling user A saves its updated DOM tree back to disk,
replacing the original file
4. The thread handling user B saves its updated DOM tree back to disk,
replacing the file containing the updates just saved for user A

Is the above something that can happen, using IIS 5 and ASP script?

Of course

If so, would storing a FreeThreadedDOMDocument.4.0 in the Application
variable be a good way to fix this, or are there any better
approaches?

Any help on this would be appreciated, since I am a little lost when
it comes to threading and asp.

What are you trying to prevent? Shouldn't both users be allowed to save
their changes? Isn't user B allowed to overwrite changes made by user A?

It sounds like you need to use a database rather than XML or a file.
--
Microsoft MVP -- ASP/ASP.NET
Please reply to the newsgroup. The email account listed in my From
header is my spam trap, so I don't check it very often. You will get a
quicker response by posting to the newsgroup.

Bob,

thanks for your reply. What I am trying to prevent is user B
effectively clearing any additions/removals made by user A. In my
scenario they both start off with identical DOM trees (in different
threads), due to the fact that they happened to submit their forms at
the same time. Now, suppose user A added elements to the DOM tree
before it was saved, then those elements would get lost when the DOM
tree from user B was saved to disk, since those elements were not
part of the user B's original DOM.

I could use a database, but I would prefer to be able to use the tree
structure of a DOM. That is why I thought that a shared in-memory DOM
tree (FreeThreaded), stored in the Application variable, would fix
the problem described above and below. Is there any reason why this
approach would not work?

Mats Olsson wrote:

Bob,

thanks for your reply. What I am trying to prevent is user B
effectively clearing any additions/removals made by user A. In my
scenario they both start off with identical DOM trees (in different
threads), due to the fact that they happened to submit their forms at
the same time. Now, suppose user A added elements to the DOM tree
before it was saved, then those elements would get lost when the DOM
tree from user B was saved to disk, since those elements were not
part of the user B's original DOM.

I could use a database, but I would prefer to be able to use the tree
structure of a DOM. That is why I thought that a shared in-memory DOM
tree (FreeThreaded), stored in the Application variable, would fix
the problem described above and below. Is there any reason why this
approach would not work?

Yes. You could lock the application object while user A updated the DOM,

but when user B performs his updates, his DOM document will still contain the
pre-userA-update data and will overwrite the changes made by user A, given
that you are talking about replacing the entire application dom document
with the user's dom document.

You could add attributes to the dom document nodes to indicate which nodes
were changed and only update the relevant nodes in the application document, but even this approach would not be perfect. However, it would be better
than simply overwriting the entire application dom document. The only
perfect approach would be to have a separate dom document for each user, but this is apt to take up a significant amount of server memory.

Bob Barrows
--
Microsoft MVP -- ASP/ASP.NET
Please reply to the newsgroup. The email account listed in my From
header is my spam trap, so I don't check it very often. You will get a
quicker response by posting to the newsgroup.

Bob,

thanks again, but my idea was to have one DOM only, i.e. the FreeThreaded
one stored in the Application object. The asp script handling submitted
forms would then add elements to this DOM, as well as look up existing ones in order to update them or remove them. The "worst" thing that could happen (unless I have missed something) is that the thread handling user A just
removed an element which was the update "target" for user B. But that's ok. And, of course, each asp script round would end with the DOM being saved to disk.

Do you still feel that this would not work?

Mats Olsson

"Bob Barrows [MVP]" <re******@NOyahoo.SPAMcom> skrev i meddelandet
news:um**************@tk2msftngp13.phx.gbl...

Mats Olsson wrote:

Bob,

thanks for your reply. What I am trying to prevent is user B
effectively clearing any additions/removals made by user A. In my
scenario they both start off with identical DOM trees (in different
threads), due to the fact that they happened to submit their forms at
the same time. Now, suppose user A added elements to the DOM tree
before it was saved, then those elements would get lost when the DOM
tree from user B was saved to disk, since those elements were not
part of the user B's original DOM.

I could use a database, but I would prefer to be able to use the tree
structure of a DOM. That is why I thought that a shared in-memory DOM
tree (FreeThreaded), stored in the Application variable, would fix
the problem described above and below. Is there any reason why this
approach would not work?

Yes. You could lock the application object while user A updated the DOM,

but

when user B performs his updates, his DOM document will still contain the pre-userA-update data and will overwrite the changes made by user A, given that you are talking about replacing the entire application dom document
with the user's dom document.

You could add attributes to the dom document nodes to indicate which nodes were changed and only update the relevant nodes in the application

document,

but even this approach would not be perfect. However, it would be better
than simply overwriting the entire application dom document. The only
perfect approach would be to have a separate dom document for each user,

but

this is apt to take up a significant amount of server memory.

Bob Barrows
--
Microsoft MVP -- ASP/ASP.NET
Please reply to the newsgroup. The email account listed in my From
header is my spam trap, so I don't check it very often. You will get a
quicker response by posting to the newsgroup.

Bob,

thanks again, but my idea was to have one DOM only, i.e. the
FreeThreaded one stored in the Application object. The asp script
handling submitted forms would then add elements to this DOM, as well
as look up existing ones in order to update them or remove them. The
"worst" thing that could happen (unless I have missed something) is
that the thread handling user A just removed an element which was the
update "target" for user B. But that's ok. And, of course, each asp
script round would end with the DOM being saved to disk.

Do you still feel that this would not work?

Mats Olsson

I have the following function that is to import HTML data from a URL
to a MS-SQL table:

function gethtml(str)
'on error resume next
dim xmlhttp
set xmlhttp = Server.CreateObject("MSXML2.ServerXMLHTTP")
xmlhttp.open "GET", str, false
xmlhttp.send
newcontent = trim(xmlhttp.responseText)
if err.number <> 0 then
newcontent = "Error Retrieving URL, Please try again."
end if
set xmlhttp = nothing
' response.write ("<xmp>")
response.write (newcontent)
' response.write ("</xmp>")
end function

Works almost perfectly ... the URL's HTML is sucked in but the
whitespace is converted to ?'s.

Just1Coder wrote:

I have the following function that is to import HTML data from a URL
to a MS-SQL table:

function gethtml(str)
'on error resume next
dim xmlhttp
set xmlhttp = Server.CreateObject("MSXML2.ServerXMLHTTP")
xmlhttp.open "GET", str, false
xmlhttp.send
newcontent = trim(xmlhttp.responseText)
if err.number <> 0 then
newcontent = "Error Retrieving URL, Please try again."
end if
set xmlhttp = nothing
' response.write ("<xmp>")
response.write (newcontent)
' response.write ("</xmp>")
end function

Works almost perfectly ... the URL's HTML is sucked in but the
whitespace is converted to ?'s.

You should have started your own thread instead of replying to this one.

Your problem is the lack of:
Response.ContentType = "text/xml"

Bob Barrows