0

As the title made you wonder already, shouldn't this be regarded as an exclusive or? The way I did understand the PerCall, each new request should create a new Service object, with a new set of variables, et cetera. So how is it actually possible that the lock on the file is still there?

Imagine, the file has not been closed appropriately during Request #1, shouldn't the object get disposed with the disposing of the huge Service object at the end of Request #1? Or is it possible that lock on the file is not in the hands of the Service object, but deep down in the inner Windows api mechanics, in a way, that with the ending of Request #1, the file lock still present (no correct close happened), the lock is still there? After having recycled the app pool, the lock has been gone, but shouldn't the setting of InstanceContextMode.PerCall have the same effect?

I would appreciate any technical explanation for this, well, phenomenon I have to label it. We can't call Andrew S. Tanenbaum, each time we can't handle this kind of problems, don't you agree? But I want to understand the inner circuit of these kind of issues.

kvirk
  • 97
  • 1
  • 10
  • If file wasn't closed appropriately (after usage, or at least in dispose method of your service object), then it will only get closed on next garbage collection which might happen any time. Question is - why not just close it appropriately? – Evk Oct 30 '20 at 14:26
  • Yes, that's what I am going to do, @Evk, thank you, but beforehand I was interested in the reasons for this kind of behavior. You have mentioned the GC, I would agree with that, if I would be able to understand the context correctly: I thought, that due to the PerCall annotation, the heap would be renewed on each request, so that the GC would start again from zero. I need to understand the annotation in the context of w3p worker process, app-pool, process, CLR, GC, file handle. – kvirk Oct 30 '20 at 14:40
  • No that's not what will happen. It will just do new YourService() at each call, and at the end it will call Dispose on that instance, if any. That's basically it. Renewing heap on each request is so terribly inefficient for webserver that it's certainly something that cannot happen. – Evk Oct 30 '20 at 15:02
  • I see, so at the end of Request #1 the FileStream object with the opened file handle will have no more references, still having the lock on the file, and gets GC'ed later, with the FileStream.Finalize call closing the FileStream. The call of new YourService() only resets the service variables to default. – kvirk Oct 30 '20 at 15:19
  • Yes that's correct. – Evk Oct 30 '20 at 15:21
  • Thanks a lot, @Evk, I would like to see these kind of information on the MSDN pages, the look-behind with respect to the components involved. – kvirk Oct 30 '20 at 17:43

0 Answers0