0

This one will be interesting...

I have seen many asp.net thumbnail generation tutorials / sample code, but no one has considered the problem of concurrency access when generating thumbnail image dynamically, when one or more user access the same page when the thumbnail needs to be generated.

A simple case, i have a site with property images (houses etc.), images are stored in a folder, the thumbnails are generated (for gallery) when someone first time accesses particular offer, then a handler makes the thumbnails from original larger images, the handler generate each thumbnail only once and then use the generated image in further requests.

What happens if two users access this page in the same time, the handler could run twice on the same file or more, there could be concurrency problem, file opening errors and so on (file needs to be opened for thumbnail generation).

Normally one user gets the thumbnail and other get a blank box without image till they refresh the page (since the first user triggered the thumbnail creation)

So the question is, how to avoid this situations ?

tshepang
  • 12,111
  • 21
  • 91
  • 136
Programista
  • 1,037
  • 5
  • 15
  • 38

1 Answers1

2

Normally if you are only opening the original image file for reading in order to generate the thumbnail there is no problem accesing it concurrently. Multiple users can open the same file for reading at the same time. Problems arise if you start writing at the same time.

Darin Dimitrov
  • 1,023,142
  • 271
  • 3,287
  • 2,928
  • Yes and No. Yes - there could be problem when writing at the same time, No - the thumbnail can be not saved in 100% and the browser will try at the same to read not fully saved thumbnail. Also to prevent concurrent writing you need to prevent concurrent opening, the answer is not so simple i think. – Programista Apr 17 '11 at 22:02
  • @Programista, the generated thumbnail is a copy which is different for each user. The only shared resource in this case is the file itself and as I said reading from a file concurrently doesn't pose any problem. You never write to the same shared resource in this scenario, Each user sends a request to the server, the server read a shared resource and generates a thumbnail which is written to the response. If another user performs the same request at the same time, the same shared resource will be accessed for reading, a new copy of the same thumbnail will be generated and sent to this user. – Darin Dimitrov Apr 17 '11 at 22:09
  • What the first user did with the response in his browser (whether he half saved it or not) is not really important and it doesn't interfere with the second user. A problem could arise if your site allows users to upload files from which you are generating those thumbnails. In this case you have two situations: a user can update an existing file and a user can only add new files. In the first case there could obviously be a conflict whereas in the second case no, because unless you have stored the file on the server you won't provide an id to other users which might generate thumbnails from it. – Darin Dimitrov Apr 17 '11 at 22:12
  • Nope, the generated image is the same for every user, problem is that browser could start to read the generated image when it is not saved by the first handler in 100% (besides the concurrent write). The handler checks if the image thumbnail has been generated already, but still there could be concurrent handlers. – Programista Apr 17 '11 at 22:14
  • @Programista, yes if users can read and modify a shared resource such as a file then there is a conflict. The best way to resolve this conflict is to either use a `lock` or a [ReaderWriterLockSlim](http://msdn.microsoft.com/en-us/library/system.threading.readerwriterlockslim.aspx). A `lock` will perform worse as it will allow only a single thread to access the shared resource (no matter whether it is reading or writing) whereas with a readerwriterlock you can allow multiple readers and if a write is required it will ensure that it is the only one at the same time. – Darin Dimitrov Apr 17 '11 at 22:16
  • Users can only read the resource, not modify or upload. I need to ensure that the thumbnail will be written only once, any fallowing handlers should only check thumbnail existence and response it immediately with proper cache headers. – Programista Apr 17 '11 at 22:20
  • @Programista, so in this situation, as I stated in my answer, you have absolutely no problem. You can safely release this to the wild :-) – Darin Dimitrov Apr 17 '11 at 22:21
  • I used a specialized locking mechanism (see http://stackoverflow.com/questions/5565395/better-solution-to-multithreading-riddle) in the DiskCache for the http://imageresizing.net library. This handles concurrency properly, so given 10 simultaneous requests for the same image, only the first will perform the resize - the others will wait until the image is saved, then all will return the response at the same time (from disk), with no extra RAM usage. Actually, if you're concerned about a correct implementation, why not use my library? It's open-source, and it is used by a lot of (huge) websites – Lilith River Jun 21 '11 at 23:41