使用InstanceContextMode.PerCall的WCF服务文件锁定

如何解决使用InstanceContextMode.PerCall的WCF服务文件锁定

正如标题已经让您感到疑惑的那样，这不应该被视为排他性吗？ 按照我对PerCall的理解，每个新请求都应创建一个具有一组新变量等的新Service对象。 那么实际上怎么可能仍在文件上的锁呢？

想像一下，在请求＃1期间没有适当关闭文件，难道不是在请求＃1的末尾随大型服务对象的处置而处置了该对象吗？ 或者，文件上的锁可能不是由Service对象控制，而是由内部Windows api机制深层处理，以某种方式，随着请求＃1的结束，文件锁仍然存在（不正确）关闭发生了），锁还在吗？回收应用程序池后，锁已消失，但是InstanceContextMode.PerCall的设置是否应具有相同的效果？

我很乐意对此做任何技术上的解释，我必须将其标记为现象。我们无法致电Andrew S. Tanenbaum，每次我们无法处理此类问题时，您同意吗？但是我想了解这类问题的内在回路。