a few observations around threads and finalization in BizTalk
Out of that came out a few observations to think about (some make perfect sense I guess, but I just didn't think about them until we tried, others less). Sorry for the lack of structure in this post.
BizTalk seems to re-use threads to run orchestrations (so orchestration A runs on thread 1 and finishes. another orchestration will run on thread 1 again) - this is probably due to the fact that the thread had finished and another NEW thread was started with the same id - I don't know if I can prove this reliably though.
When I dropped 100 files in our receive location only 3-4 threads were started to process them; not 100.
If I started a thread from an orchestration (through a helper class, of course) - that thread will continue to run even after the orchestration finishes.
If we stop the host while a thread is running, even if we implement a destructor (or finalize) - we only get a limited time to do so. after 40-50 seconds the thread will die , whether the destructor completed or not.
If you had multiple instances of a class in the host that implement finalize, the finalizers will be called sequentially (so that finalizer for instance B of the class will only be called after finalizer of instance A had finished), according to the previous point, after 40-50 seconds the host will stop, regardless of how many finalizers were actually called. So an instance may be terminated without the finalizer being called.