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

[Mats Olsson]

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.DOMDocum ent.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.DOMDocum ent.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?

If so, would storing a FreeThreadedDOM Document.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

[Bob Barrows [MVP]]

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

Mats Olsson wrote:[color=blue]
> 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.DOMDocum ent.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.DOMDocum ent.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?[/color]

Of course
[color=blue]
>
> If so, would storing a FreeThreadedDOM Document.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.
>[/color]

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.

[Mats Olsson]

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

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

"Bob Barrows [MVP]" <reb01501@NOyah oo.SPAMcom> wrote in message
news:uY2$cdmmEH A.392@tk2msftng p13.phx.gbl...[color=blue]
> Mats Olsson wrote:[color=green]
> > 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.DOMDocum ent.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.DOMDocum ent.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?[/color]
>
> Of course
>[color=green]
> >
> > If so, would storing a FreeThreadedDOM Document.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.
> >[/color]
>
> 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.
>
>[/color]

[Bob Barrows [MVP]]

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

Mats Olsson wrote:[color=blue]
> 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?
>[/color]

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.

[Mats Olsson]

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

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]" <reb01501@NOyah oo.SPAMcom> skrev i meddelandet
news:umJm8OomEH A.2864@tk2msftn gp13.phx.gbl...[color=blue]
> Mats Olsson wrote:[color=green]
> > 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?
> >[/color]
>
> Yes. You could lock the application object while user A updated the DOM,[/color]
but[color=blue]
> 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[/color]
document,[color=blue]
> 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,[/color]
but[color=blue]
> 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.
>
>[/color]

[Mats Olsson]

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

Oops, I actually meant the Application variable, not the Application object.
Mats

"Mats Olsson" <nospam@nodomai n.com> skrev i meddelandet
news:_1I1d.1033 58$dP1.371467@n ewsc.telia.net. ..[color=blue]
> 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[/color]
ones[color=blue]
> in order to update them or remove them. The "worst" thing that could[/color]
happen[color=blue]
> (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[/color]
ok.[color=blue]
> And, of course, each asp script round would end with the DOM being saved[/color]
to[color=blue]
> disk.
>
> Do you still feel that this would not work?
>
> Mats Olsson
>
> "Bob Barrows [MVP]" <reb01501@NOyah oo.SPAMcom> skrev i meddelandet
> news:umJm8OomEH A.2864@tk2msftn gp13.phx.gbl...[color=green]
> > Mats Olsson wrote:[color=darkred]
> > > 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?
> > >[/color]
> >
> > Yes. You could lock the application object while user A updated the DOM,[/color]
> but[color=green]
> > when user B performs his updates, his DOM document will still contain[/color][/color]
the[color=blue][color=green]
> > pre-userA-update data and will overwrite the changes made by user A,[/color][/color]
given[color=blue][color=green]
> > 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[/color][/color]
nodes[color=blue][color=green]
> > were changed and only update the relevant nodes in the application[/color]
> document,[color=green]
> > 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,[/color]
> but[color=green]
> > 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.
> >
> >[/color]
>
>[/color]

[Bob Barrows [MVP]]

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

The "Save to disk" part is where you will run into problems if I understand
what you mean by "each asp script round". When the DOM in Application is
saved to disk, it will completely overwrite the disk version.

You're really better off using a database when concurrency is an issue. I
can't stress that enough.


Mats Olsson wrote:[color=blue]
> 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
>[/color]
--
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.

[Just1Coder]

ServerXMLHTTP

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.CreateOb ject("MSXML2.Se rverXMLHTTP")
xmlhttp.open "GET", str, false
xmlhttp.send
newcontent = trim(xmlhttp.re sponseText)
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.

[Bob Barrows [MVP]]

Re: ServerXMLHTTP

Just1Coder wrote:[color=blue]
> 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.CreateOb ject("MSXML2.Se rverXMLHTTP")
> xmlhttp.open "GET", str, false
> xmlhttp.send
> newcontent = trim(xmlhttp.re sponseText)
> 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.[/color]

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

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

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.

[Just1Coder]

Re: ServerXMLHTTP

Thanks Bob.

Bob Barrows [MVP] wrote:[color=blue]
> Just1Coder wrote:
>[color=green]
>>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.CreateOb ject("MSXML2.Se rverXMLHTTP")
>>xmlhttp.ope n "GET", str, false
>>xmlhttp.sen d
>>newcontent = trim(xmlhttp.re sponseText)
>>if err.number <> 0 then
>>newcontent = "Error Retrieving URL, Please try again."
>>end if
>>set xmlhttp = nothing
>>' response.write ("<xmp>")
>>response.writ e (newcontent)
>>' response.write ("</xmp>")
>>end function
>>
>>Works almost perfectly ... the URL's HTML is sucked in but the
>>whitespace is converted to ?'s.[/color]
>
>
> You should have started your own thread instead of replying to this one.
>
> Your problem is the lack of:
> Response.Conten tType = "text/xml"
>
> Bob Barrows[/color]