如何为PAC运算设定请求集

由于第一支PAC:定期请购成本处理程序 请求在运行过程中会自动提交 定期实际成本处理程序 请求,且 这两个请求不存在父子关系,导致 第二个请求尚未处理完成时 第一个请求已经运行完成,这就导致在设定请求集时无法设定 链接阶段。 第二支PAC情况也是一样。

思路:设定 第二支PAC请求 :期间平均成本处理程序 和第三支PAC请求:定期成本分配处理程序,均与 定期实际成本处理程序 不兼容,这样一旦 定期实际成本处理程序 处于运行状态时,第二支和第三支请求即会处于等待状态。如下图:

这样设定完后还有一个问题:当第一支 或者 第二支PAC请求触发 定期实际成本处理程序 请求时由于自身也已经完成,这就导致下一阶段(第二支PAC或第三支PAC)开始运行,所以:定期实际成本处理程序 和 下一阶段(第二支PAC或第三支PAC)很可能同时处于待定状态,这个时候发现即使设定了兼容也存在不确定因素,有时先跑前者,有时又先跑后者,导致最终运行失败(这里我也将 优先级 设定上去测试过,但是结果还是一样)

解决办法:加入 Oracle自带的休眠请求,如下:这边需注意,需要定义下这个请求,标准仅提供了 pl/sql存储过程,未提供这个请求,需新定义下:

这边如果不给默认值,系统标准默认值为:20秒,给了默认值的好处是当请求集运行时还可以调整这个参数值,这边的值需根据系统资源情况来设定:其主要作用就是延迟下一阶段开始 运行,以便让 定期实际成本处理程序 请求已经处于运行状态,这样第二只或第三支PAC由于不兼容自然会处于等待状态(因此这边的休眠时间主要看服务器处理 冲突请求的反映时间快慢,如果慢的话设定时间稍微长点)。

最终设定如下图:

注意:由于第3支PAC均基于前面一支请求,当前面一支请求尚未跑完,后面一支请求是选择不到期间的,因此在PAC期间刚打开时,需要先跑下第一支和第二支请求,这样请求集才能赋值参数。(或者 改变系统标准值集也行)

延迟到  定期实际成本处理程序 请求运行中 则成功处理请求集

如何为PAC运算设定请求集

时间: 2024-08-11 01:18:37

如何为PAC运算设定请求集的相关文章

【EBS】并发请求/请求集挂到菜单功能

并发请求/请求集挂到菜单功能 通常并发请求是通过点击菜单栏"查看"→"请求"来提交,通常为了操作方便,希望能像其他表单一样挂到菜单中. 定义功能时,选择"表单"标签页,表单字段选择"运行报表",参数字段填写如下内容: CONCURRENT_PROGRAM_NAME="CUX_XXXXXXXX" PROGRAM_APPL_SHORT_NAME="CUX" CONCURRENT_PROGRA

Nginx详解-服务器集群

Nginx是什么 代理服务器:一般是指局域网内部的机器通过代理服务器发送请求到互联网上的服务器,代理服务器一般作用在客户端.应用比如:GoAgent,FQ神器.  一个完整的代理请求过程为:客户端首先与代理服务器创建连接,接着根据代理服务器所使用的代理协议,请求对目标服务器创建连接.或者获得目标服务器的指定资源. Web代理(proxy)服务器是网络的中间实体. 代理位于Web客户端和Web服务器之间,扮演“中间人”的角色.HTTP的代理服务器即是Web服务器又是Web客户端. 代理服务器是介于

架构设计:系统存储(18)——Redis集群方案:高性能

1.概述 通过上一篇文章(<架构设计:系统存储(17)--Redis集群方案:高可用>)的内容,Redis主从复制的基本功能和进行Redis高可用集群监控的Sentinel基本功能基本呈现给了读者.虽然本人并不清楚上一篇根据笔者实际工作经验所撰写的文章有什么重大问题,导致那么多朋友集体点踩而且截止目前又没有任何人愿意为笔者指出这些问题,但是这不会影响笔者继续学习.总结技术知识的热情.从这篇文章开始我们一起来讨论Redis中两种高性能集群方案,并且在讨论过程中将上一篇文章介绍的高可用集群方案结合

集群之LVS(负载均衡)详解

提高服务器响应能力的方法 scale on  在原有服务器的基础上进行升级或者直接换一台新的性能更高的服务器. scale out  横向扩展,将多台服务器并发向外响应客户端的请求.优点:成本低,扩展架构比较简单. 集群(Cluster),通俗地讲就是按照某种组织方式将几台电脑组织起来完成某种特定任务的这样一种架构. 三种集群类型: LB,Load Balancing 负载均衡:在一定程度上能够实现高可用的目的. HA,High Availability 高可用:实时在线,能够及时响应客户端请求

Nginx详解-服务器集群(转载)

Nginx是什么 代理服务器:一般是指局域网内部的机器通过代理服务器发送请求到互联网上的服务器,代理服务器一般作用在客户端.应用比如:GoAgent,FQ神器.  一个完整的代理请求过程为:客户端首先与代理服务器创建连接,接着根据代理服务器所使用的代理协议,请求对目标服务器创建连接.或者获得目标服务器的指定资源. Web代理(proxy)服务器是网络的中间实体. 代理位于Web客户端和Web服务器之间,扮演"中间人"的角色.HTTP的代理服务器即是Web服务器又是Web客户端. 代理服

集群之Haproxy

haproxy HAProxy提供高可用性.负载均衡以及基于TCP和HTTP应用的代理,支持虚拟主机,它是免费.快速并且可靠的一种解决方案.HAProxy特别适用于那些负载特大的web站点,这些站点通常又需要会话保持或七层处理.HAProxy运行在当前的硬件上,完全可以支持数以万计的并发连接.并且它的运行模式使得它可以很简单安全的整合进您当前的架构中, 同时可以保护你的web服务器不被暴露到网络上. HAProxy实现了一种事件驱动, 单一进程模型,此模型支持非常大的并发连接数.多进程或多线程模

搭建LVS+Keepalived+nginx+tomcat高可用性,高性能jsp集群

LVS-master:192.168.0.210 LVS-backup:192.168.0.211 LVS-VIP:192.168.0.209 nginx+tomcat:192.168.0.212 nginx+tomcat:192.168.0.227 安装nginx所需包: Nginx-1.6.0.tar.gz和pcre-8.35.zip 一.安装pcre-8.35 1 #unzip pcre-8.35.zip 2 #cd pcre-8.35 3 #./configure 4 #make 5 #

nginx实现请求的负载均衡 + keepalived实现nginx的高可用

前言 使用集群是网站解决高并发.海量数据问题的常用手段.当一台服务器的处理能力.存储空间不足时,不要企图去换更强大的服务器,对大型网站而言,不管多么强大的服务器,都满足不了网站持续增长的业务需求.这种情况下,更恰当的做法是增加一台服务器分担原有服务器的访问及存储压力.通过负载均衡调度服务器,将来自浏览器的访问请求分发到应用服务器集群中的任何一台服务器上,如果有更多的用户,就在集群中加入更多的应用服务器,使应用服务器的负载压力不再成为整个网站的瓶颈. 摘自<大型网站技术架构_核心原理与案例分析>

基于请求的分布式互斥算法

一个悲剧的文章,研究的东西确实比较老,但是因为这些研究,让我对分布式的底层的关系有了更加清晰的认识,也算是不枉此功. 下面贴出来核心的部分. 引言 分布式系统中的一组进程可能会同时访问一个资源或者同时执行一个给定的函数,我们称这些资源或者函数为临界区(Critical Section),若不加控制的话,会造成资源或者环境的不一致的现象.保证任何给定时刻只允许一个进程或者给定的进程去执行临界区的算法称为互斥算法.互斥也可以称为并发控制. 这个问题最早由Dijkstra[1]在1965年提出.互斥可