Synchronising downloads and updates

  • Thread starter Thread starter Peter Morris
  • Start date Start date
Hi all

I've just blogged about an approach I have taken for a specific multi-user
scenario, uploading a new version of a file while other users are
downloading (website).

http://mrpmorris.blogspot.com/2009/03/synchronising-downloads-and-upd...

If anyone can see any pitfalls or something in my approach I'd like to hear
about it, so that the problem doesn't get released into a production app.
Click to expand...

I don't see any problems with sync code - in fact, it's a good example
of using RWL where it's actually useful. However...

What happens if the write request sits in the RWL queue for too long
(i.e. there are too many users out there... or maybe just one guy, but
he's on dial-up)? Wouldn't that time out the POST request eventually,
discarding the file data?

Depending on how frequent and/or annoying that may be, I'd rather
upload a file to a temp location first, and then launch a background
service that would wait for the lock for however long it takes to move
it to the final destination. Maybe even with a bit of AJAX flashiness
to tell the user what's going on, if he's inclined to watch, not
navigating away from the page after the file had been uploaded.
 
Thanks Pavel
What happens if the write request sits in the RWL queue for too long
(i.e. there are too many users out there... or maybe just one guy, but
he's on dial-up)? Wouldn't that time out the POST request eventually,
discarding the file data?
<

Yes, I expect it would, but that would really be a desired behavior. As
soon as the write lock is attempted no more read locks will be permitted, so
if the existing user is on dial up and a write lock is attempted then all
other people will be blocked from reading until the write lock is satisfied
or disposed of. If the POST request times out then the finally blocks will
be executed and the WriteLock will be aborted, freeing up other readers
again in a shorter time than it would take for the modem user to finish.

I expect really I need to check if I have the read / write lock before
Exiting it, because my code could actually be executing from an exception.
I knew there would be something I hadn't thought of, thanks :-)


Pete
 
I expect really I need to check if I have the read / write lock before
Exiting it, because my code could actually be executing from an exception.
I knew there would be something I hadn't thought of, thanks :-)
Click to expand...

Nope, because the code immediately after the EnterReadLock / ExitReadLock is
the using() command so it is a try..finally. If I have my thread aborted
then it will be before the lock is acquired. If the lock is acquired then
the next code is a try..finally so I should be okay :-)
 
What happens if the write request sits in the RWL queue for too long
(i.e. there are too many users out there... or maybe just one guy, but
he's on dial-up)? Wouldn't that time out the POST request eventually,
discarding the file data?
<

Yes, I expect it would, but that would really be a desired behavior.  As
soon as the write lock is attempted no more read locks will be permitted,so
if the existing user is on dial up and a write lock is attempted then all
other people will be blocked from reading until the write lock is satisfied
or disposed of.  If the POST request times out then the finally blocks will
be executed and the WriteLock will be aborted, freeing up other readers
again in a shorter time than it would take for the modem user to finish.
Click to expand...

I did not mean this from the locking perspective, I meant this from
the user experience perspective :)

From your description of the problem, it seems that the uploading user
would really, really want the upload to be successful from the first
try. In which case that aborted POST can be frustrating, as the
uploader would have to go through the entire process once again (and
specifically, re-send all file data).
 
Back
Top