none
关于BizTalk多机死锁问题 RRS feed

 > 

  • 问题

  • Question
    登录进行投票
    0
    登录进行投票

    在部署时，有两台服务器，我们采用的是两台服务器加入到一个组中，但在访问SQL数据库是，恨容易造成两台服务器的冲突，然后死锁。不知道这种情况怎么解决，如果不行，我们只有考虑把两台服务器部署成群集，但这样性能上又差了些。
    请教各位大侠指点一二，十分谢谢！

    2009年5月25日 7:15
    |

全部回复

  • Question
    登录进行投票
    0
    登录进行投票
    这个跟你的设计有关，对于SQL数据库同时做大量insert、update等操作的时候很容易造成SQL Server死锁，可以在SQL语句中声明ROWLOCK来缓解这个问题。另外对于SQL Server可以考虑最新的WCF-SQL来连接。在性能和扩展性方面有进一步的提高。
    关于数据库中的涉及排序等方面的问题可以参考一下SQL Server Service Broker看能不能解决，如果可以的话也可以使用Server Broker。这样可以有效的解决死锁和大数据并发的处理量问题。
    2009年5月27日 9:59
    |
  • Question
    登录进行投票
    0
    登录进行投票
    感谢版主的回答，能不能请您说具体一些，最好是也是这样多台服务器的环境，需要注意哪些问题、那些是很关键的步骤等。
    2009年6月2日 2:54
    |
  • Question
    登录进行投票
    0
    登录进行投票
    这种解决方案跟你的业务关系很紧密。我建议你看一下SQL Server Service Broker，这是一种在数据库里实现并发业务处理排队的技术，看能不能解决你的问题。另外BizTalk扩展方案在多机运行时的问题在程序设计时要考虑到一是资源的访问冲突，不过这个微软已经解决了。只要是支持高性能解决方案的适配器都可以。但像FTP这类的适配器不支持多机运行。另外要考虑如果在程序运行过程中对资源的访问和临时文件的生成等。由于不同的资源是在运行时可能产生在不同的机器上的。这些资源怎么访问和清除得考虑。
    2009年6月2日 3:03
    |
  • Question
    登录进行投票
    0
    登录进行投票
    现在我们改变了BizeTalk的部署方式，做成了群集。按照BizeTalk的文档，在windows群集中添加了DTC资源组和BizeTalk的资源组，安装好BizeTalk。在测试群集时，我们把节点二停止或者关闭，资源组能快速地正常地切换到节点一。但是在关闭或者重启节点一时，资源组切向节点二，等待几钟后，出现DTC资源和BizeTalk的两个实例不能正常联机，只有当节点一启动之后，资源才能正常联机。也就是说，从节点二切到节点一是没有任何问题的，但从节点一切到节点二必须依赖节点一的正常工作，否则不能成功。
    我想请教一下，这种情况是什么原因引起的？有没有工具和方法来查看是什么原因导致这种情况的出现？
    2009年6月11日 6:00
    |
  • Question
    登录进行投票
    0
    登录进行投票

    这个跟你们BizTalk群集的结构模式相关，如果将两台BizTalk服务器加入到一个组中，那样的话应该有一个主Biztalk管理数据库，因此任何时候主Biztalk都必须正常才能保证BizTalk群集的运行。。。

    具体的群集部署可以参考Biztalk 的群集安装文档bts06r2_install_multi.doc，，

    2009年6月19日 13:22
    |
  • Question
    登录进行投票
    0
    登录进行投票
    因为biztalk的所有操作都是基于事务的，如果是多机部署就是基于分布式事务的。
    SQL adapter也不例外，并且事务隔离级别是最高级别Serializable 的，这意味着，只要某个连接比如说是连接A用select 访问一个table时，这个table1就是被范围锁锁住的状态，如果这个时候又有一个连接B要更新table1时就必须等待连接A释放table1。再稍微复杂点，连接A访问完table1后还有去访问table2，连接B在访问table1之前先访问table2，事情就可能发生了连接A访问了table1后要去访问table2，同时连接B访问完了table2要去访问table1，但是这时tabel1被连接A锁着，table2被连接B锁着，B在等A释放table1的锁，A在等B释放table2，这就死锁了。
    这种情况，两个连接在第一次访问table1和table2时都是select访问，这时没必要把这个两个表用范围锁锁住（锁在当前事务完成后才能释放），只要设置为共享锁（select语句执行完锁即释放）能避免脏读即可，就是把select语句部分设置为“Read Committed”即可，这样table1,table2在select时就不会被锁，后面的访问也就不会被死锁。

    所以在SQL adapter的sql语句中，把所有的select语句都加上‘With (Readcommitted)’ 覆盖默认的Serializeable ，比如这样：Select * from authors with (Readcommitted) where contract = 1

    这样应该可以解决绝大部分的死锁问题。
    专注于biztalk。 chnking.cnblogs.com
    2009年7月5日 3:16
    |