BizTalk 2009文件适配器发送时存在附加锁定问题

BizTalk 2009文件适配器发送时存在附加锁定问题,biztalk,biztalk-2009,Biztalk,Biztalk 2009,我们的BizTalk server中有一些EDI文件,我们将这些文件放在文件共享中,供终端系统处理。这些文件通过带有静态文件名的单个文件发送端口拖放到文件共享中。由于终端系统每天仅收集一次文件,因此文件随附加选项一起交付 我们正在为发送端口运行一个主机实例。文件共享位于单独的服务器上。当我们转到该服务器(Widnows 2008)并查看打开的文件时,我们会看到来自BizTalk主机实例帐户的文件上有两个读取锁。这些消息在BizTalk中挂起,其中包含拒绝访问的消息。文件被写入文件共享,以分钟分隔

我们的BizTalk server中有一些EDI文件,我们将这些文件放在文件共享中,供终端系统处理。这些文件通过带有静态文件名的单个文件发送端口拖放到文件共享中。由于终端系统每天仅收集一次文件,因此文件随附加选项一起交付

我们正在为发送端口运行一个主机实例。文件共享位于单独的服务器上。当我们转到该服务器(Widnows 2008)并查看打开的文件时,我们会看到来自BizTalk主机实例帐户的文件上有两个读取锁。这些消息在BizTalk中挂起,其中包含拒绝访问的消息。文件被写入文件共享,以分钟分隔,有时在同一分钟内。没有一个文件是大的(都<20K)。这种情况可能每周发生一次,发生在目标服务器上的不同文件放置位置。回收主机实例不会释放锁。定货没有用

任何解决问题或排除故障的想法或输入都会有所帮助。我一直在考虑的一些事情:

  • 文件适配器丢失其文件句柄
  • 有人在文件适配器中使用附加模式之前没有问题吗

  • 谢谢

    事实证明,这是BizTalk文件适配器的一个已知问题

    “这是追加选项的问题,因为Biztalk在追加之前读取到文件的结尾。”


    如果不使用附加模式,您是否仍然会遇到问题?我通常会不惜一切代价避免使用文件。你不能使用像msmq这样的不同传输吗?我们被锁定在文件中。。。如果需要的话,我们可以使用FTP,但这是不可取的。这个问题只表现在附加模式写入上。根据我的经验,文件删除并不是真正为可靠的数据传输而设计的。我认为FTP更好。