Re: ASP.NET file system operations...should file writes use locks?

[Jon Skeet [C# MVP]]

On Jun 3, 8:12 am, moo <[e-mail]:

<snip>

My question is: do I need that lock?

I seriously doubt that it'll be doing anything useful at the moment.
You're locking on "this", but a new page instance is created for each
request, I believe.

My initial feeling is that since
I'm creating a file name based upon the names entered in the fields (I
should probably sanitize those inputs..aside from regexs looking for A-
Z, any other checking ideas I should do would be welcome), I may
someday have the odd condition where two users are entering
information for the same person and happen to click the button at the
same time, possibly creating a race condition. Is that accurate?

I would suggest creating a file with a temporary filename (e.g.
creating a new GUID and using that) and then modify EmailOverseer so
it can send the attachment *as if* the file had the desired filename.

In fact, does EmailOverseer really need the file to be on disk in the
first place? Any reason you can't use memory directly? (e.g.
MemoryStream)

Jon

[moo]

Good point...I was thinking I needed to instantiate a file object and
then lock on that object, but I tried to get lazy and use the static
method (because a couple of bytes on the stack are all so
important...*smacks self*) without thinking it through.

Thanks for your suggestion, I can probably do that...this is more of a
proof in concept solution, and the dumb and lazy approach is to
automatically generate the report in a file and then attach that file
to the e-mail...if I want to get fancy I may want to generate an XML
so I can e-mail it out in HTML format and have a source for back end
queries later, but that's another topic...

The main gist of the question was, what are some standard patterns/
best known methods for handling file system interactions in ASP.NET?
Do we treat them similarly to multi-threaded console apps, or are
there other considerations we need to account for/simplify things? Any
specific resources would be welcome.

On Jun 3, 1:44 am, "Jon Skeet [C# MVP]" <[e-mail]:

On Jun 3, 8:12 am, moo <[e-mail]:

<snip>

My question is: do I need that lock?

I seriously doubt that it'll be doing anything useful at the moment.
You're locking on "this", but a new page instance is created for each
request, I believe.

My initial feeling is that since
I'm creating a file name based upon the names entered in the fields (I
should probably sanitize those inputs..aside from regexs looking for A-
Z, any other checking ideas I should do would be welcome), I may
someday have the odd condition where two users are entering
information for the same person and happen to click the button at the
same time, possibly creating a race condition. Is that accurate?

I would suggest creating a file with a temporary filename (e.g.
creating a new GUID and using that) and then modify EmailOverseer so
it can send the attachment *as if* the file had the desired filename.

In fact, does EmailOverseer really need the file to be on disk in the
first place? Any reason you can't use memory directly? (e.g.
MemoryStream)

Jon

[Jon Skeet [C# MVP]]

moo <nt*****@gmail.comwrote:

Good point...I was thinking I needed to instantiate a file object and
then lock on that object, but I tried to get lazy and use the static
method (because a couple of bytes on the stack are all so
important...*smacks self*) without thinking it through.

Thanks for your suggestion, I can probably do that...this is more of a
proof in concept solution, and the dumb and lazy approach is to
automatically generate the report in a file and then attach that file
to the e-mail...if I want to get fancy I may want to generate an XML
so I can e-mail it out in HTML format and have a source for back end
queries later, but that's another topic...

The main gist of the question was, what are some standard patterns/
best known methods for handling file system interactions in ASP.NET?
Do we treat them similarly to multi-threaded console apps, or are
there other considerations we need to account for/simplify things? Any
specific resources would be welcome.

I haven't heard of any particular rules - I'd just say:

1) Writes should usually be to different files anyway, apart from for
logging (lock in that case)
2) Concurrent reads should be fine (open shared) so long as you don't
have anything else writing
3) Try to avoid it in the first place if possible

--
Jon Skeet - <sk***@pobox.com>
Web site: http://www.pobox.com/~skeet
Blog: http://www.msmvps.com/jon.skeet
C# in Depth: http://csharpindepth.com