More file locking problems

[darrel]

I've been dealing with a file locking issue for a while.

Our CMS spits out a new XML file each time an item in the DB is updated.
This XML file is basically our site menu, and is what we use on the front
end to render out site's navigation, site map, breadcrumbs, etc.

We're using it because it's more efficient to just cache the XML file rather
than doing recursive DB calls on each page load.

We ran into a problem where, as far as we can tell, once in a great while,
two people would try to save the same file at the exact same time,
interupting the first file write and leaving only half of an XML file in the
filesystem, which, obviously, is invalid, thereby breaking our site.

So, we started doing file locking. If the file is being written, nothing
else is supposed to write to it. Which isn't a big deal, as the next person
to edit any other page will, in turn, update the XML file when they save.

We thought that fixed things, but now we're back to the same problem + a new
one.

So, my questions:

1) Is there any way to log/test for the incomplete XML file? I'm thinking
that one option is every time any page in the system (be it on the admin
side or public side) needs to to access the XML file, and it's invalid, that
it callse the function to rewrite it and then tries to execute again. Alas,
that seems REALLY hacky and open to all sorts of nasty logic loops.

Any other ideas?

2) Another issue is that one of the XML files that was half-written is also
now locked by another process, so I can't even write a new file if I want to
until I reboot asp.net on the server. Any way to see what is currently
locking a file?

I hope others are having a more enjoyable Friday afternoon ;o)

-Darrel

[darrel]

I have a hunch that rtvscan might be the culprit (norton).

Anyone have any experience with that? I assume it may be scanning files that
are being created and then locking them.

-Darrel

[Jeff Dillon]

Why don't you write the XML back to the database, instead of the file
system. SQL supports an XML datatype, or just save it as text

Jeff
"darrel" <no*****@nowhere.com> wrote in message
news:e8**************@TK2MSFTNGP03.phx.gbl...

I've been dealing with a file locking issue for a while.

Our CMS spits out a new XML file each time an item in the DB is updated.
This XML file is basically our site menu, and is what we use on the front
end to render out site's navigation, site map, breadcrumbs, etc.

We're using it because it's more efficient to just cache the XML file
rather than doing recursive DB calls on each page load.

We ran into a problem where, as far as we can tell, once in a great while,
two people would try to save the same file at the exact same time,
interupting the first file write and leaving only half of an XML file in
the filesystem, which, obviously, is invalid, thereby breaking our site.

So, we started doing file locking. If the file is being written, nothing
else is supposed to write to it. Which isn't a big deal, as the next
person to edit any other page will, in turn, update the XML file when they
save.

We thought that fixed things, but now we're back to the same problem + a
new one.

So, my questions:

1) Is there any way to log/test for the incomplete XML file? I'm thinking
that one option is every time any page in the system (be it on the admin
side or public side) needs to to access the XML file, and it's invalid,
that it callse the function to rewrite it and then tries to execute again.
Alas, that seems REALLY hacky and open to all sorts of nasty logic loops.

Any other ideas?

2) Another issue is that one of the XML files that was half-written is
also now locked by another process, so I can't even write a new file if I
want to until I reboot asp.net on the server. Any way to see what is
currently locking a file?

I hope others are having a more enjoyable Friday afternoon ;o)

-Darrel

[darrel]

Well, killing asp.net and forcing it to restart released the file, so I
suppose it's an issue with my application. I'm obviously missing a proper
FINALLY statement in a try/catch somewhere...

-Darrel

[darrel]

> Why don't you write the XML back to the database, instead of the file

system. SQL supports an XML datatype, or just save it as text

Hmm...ya know, that might be the best way to go about this.

The reason we were using the XML file was that it was easily cached by the
system. I can easily check to see if the file has been updated, and, if not,
just use the cache.

I assume with the DB solution, I'd have to always query the DB on each page
load to see if it's a new file (or is that assumption wrong)?

-Darrel