关于我

<2020年4月>
2930311234
567891011
12131415161718
19202122232425
262728293012
3456789

最近来访

加入的俱乐部

留言簿(0)

文章分类

文章档案

相册


最新评论

1. re: 使用OpenSSL制作SSL證書
感谢,很有帮助--【匿名用户】:E-works热心网友 小雪
2. re: 使用OpenSSL制作SSL證書
受益匪浅,非常感谢~--【匿名用户】:E-works热心网友 落叶无边
3. re: 使用OpenSSL制作SSL證書
不错,很详细--【匿名用户】:E-works热心网友
4. re: EDI X12 SPEC从哪来?和大家讨论
--holger
5. re: EDI X12 SPEC从哪来?和大家讨论
根据业务需求分析得到--【匿名用户】:E-works热心网友
6. re: 【译】ANSI ASC X12标准学习指南
well&nbsp;done,i&nbsp;guess&nbsp;you&nbsp;worked&nbsp;in&nbsp;fox&nbsp;--【匿名用户】:E-works热心网友
7. re: 【译】ANSI ASC X12标准学习指南
概述很全面......--【匿名用户】:E-works热心网友
8. re: EDI SPEC从哪来?和大家讨论
您可以到Rosettanet官方网站看看有没有您想要的资料。--传奇

阅读排行榜

评论排行榜

在多进程环境中,有一些资源经常会被不同进程的线程所访问,如果不对这种境况采取一些措施的话,可能会在应用系统中造成一些无法预料的问题。在BusinessWorks (BW) 应用程序中,这样的问题同样需要引起注意。幸运的是,BW提供了一些防止这些多进程问题的方式。本文将介绍如何针对BW的多进程进行一些特殊的设计。

进程进程实例排序

在默认情况下,BW引擎不会维护事件或者消息接受的顺序,而用户常常会需要这种顺序的维护。如果这种顺序可以被控制,BW process能够顺序地接收消息或者事件,一些并发的问题就会被避免,而且BW process的设计也可以被简化。BW有两种方式来控制这种process的顺序执行

1.       部署配置

用户可以通过TIBCO Administrator控制进程实例在内存中的最大数量和最大的并发数量。利用这些设置,用户可以使指定的Process的进程实例动态的创建。

 

 

设置Max Jobs = 1,并且选中Use Activation Limit就可以使Process的进程实例顺序执行。

2.       Process Starter配置

另一个选择,在BW的设计时,可以为Process Starter设置Sequencing Key,指定Process的顺序执行。配置有Sequencing Key的进程实例在他们启动时会根据Sequencing Key的值来进行顺序执行。进程实例的Sequencing Key的值可以不同,但是只有相同值的进程实例才会顺序执行,不同值的实例仍会并发执行。

 

 

在上图中,将JMS消息体中的一个元素设置为Sequencing Key. 如果JMS消息发送方每次发送的消息中这个元素的值是个常量 (比如10),这个Process就会顺序执行。在TIBCO DesignerTester中,我们会发现进程实例接收到消息,但是并没有马上执行,他们是在一个进程实例完成后,另一个才执行的,以此顺序处理所有的消息。

如果Sequencing Key的值不是一样的,或者没有进行设置,进程实例就会并发执行。

 

进程同步

在有些场景中,资源是被不同的Process访问的。这些Process可能会并发的访问这些资源,如果不使用一些同步的措施,可能会读到脏数据。BW提供了Critical Section来保护这些重要的资源。

 

 

Process中添加一个 Group Activity,设置这个GroupAction类型为Critical SectionCritical Section有两种Scope属性,Single GroupMultiple Group

Single Group在一个Process的所有进程实例中有效。比如,在一个Process中创建Critical Section。在运行时,这个Process会创建多个进程实例。这些进程实例运行到Critical Section中的时候将会被同步,其他的进程实例需要等待占用Critical Section的进程实例在Section中运行完毕才可以访问Critical Section。在其他Process中的Critical Section不会影响当前进程中的Single GroupCritical Section

Multiple Group在不同的Process的进程实例中有效,并且可以跨越不同的Process EngineMultiple Group使用Lock Object在不同的Critical Section之间进行同步。使用相同的Lock ObjectMultiple Group机会被同步,即使这些Critical Section在不同的Process中或者Engine中。

 

 

在上图中,有两个Critical Section,都被设置为Multiple Group并且使用相同的Lock Object。如果这个进程的实例被运行,当运行到一个Section的时候,另一个Section会等待,直到当前运行的Critical Section运行完毕释放Lock Object,才会运行。在不同的Process中,结果也是相同的。

需要注意的问题

通常,这些同步的操作会降低应用系统的性能。要避免在Critical Section中使用下列的Activity

Wait-forSleepRequestReply和其他所有需要花较长时间来运行的Activity

要避免Critical Section嵌套。

发表于: 2014-05-25 18:35 阅读(603) 评论(0) 收藏 好文推荐

本博客所有内容,若无特殊声明,皆为博主原创作品,未经博主授权,任何人不得复制、转载、摘编等任何方式进行使用和传播。

作者该类其他博文:

发表评论(网友发言只代表个人观点,不代表本网站观点或立场。)

您尚未登录,请先【登录或注册