This content has been marked as final. Show 5 replies
You could place a read-only lock around the code that displays the image, and an exclusive lock around the code that does the delete. If the picture is being displayed, the deletion code will wait until the read-only lock is released.
I fear this may have a deleterious effect on performance. To do an extra lock on each file as it's being served, in addition to the system file lock, may slow performance to unacceptible levels. Particularly since there are a large number of thumbnails being loaded and displayed on the main page (apologies for not mentioning that in my initial post). I would think putting the admin app in a loop until the system file lock is released before doing anything to the file in question would be a much more efficient use of cycles in this particular scenario. Any other thoughts out there?
If you are sure that this is a file-sharing problem, something very basic could work. For example,
<!--- Attempt to delete file --->
<!--- Make a pause for N seconds and try again --->
I'd go with Mr. Black.
You could also try to rename the fale ( rename it back) to test if the file is locked.
If waiting for the file to become unlocked is slowing down performance, you could outsource the delete-file operation into a separate file, call that by cfhttp with a low cfhttp-timeout but a high request-timeout.
That way your application does not have to wait since the delete-file process (with waiting, etc.) is running in separate request on the server. Of course you would not know when the file is actually being deleted, but you don't have to wait for it either.
p.s. "Separate file called by cfHTTP" could be a webservice nowadays.
if you're running Enterprise edition, the delete function sounds like a job that should be delegated to an Asynchronous Event Gateway.