一点BPXA的思考

懂的人自然懂。。。

BPXA功能配置

这个概念现在还有印象,记录下来:

一,BPXA是用于BP使用第三方资源的。如使用ORACLE数据库,就是在XA里配置。它的特征是以<xa>开头

二,BPXA有自己的KCXP队列。这个队列是自己的,还是寄生在已有的KCXP队列中,无影响。

三,BPXA在配置KCBP之间的交换资源时,是将一个BP里的队列转发到另一个队列里去。

四,所以,源BP队列里是要配置TRANSFER队列,且收发和DISPATCH配置相反。(SEND,REQ,RECEIVE,ANS)。

五,中转BPXA将源BP队列放入自己的自己的队列,且建立侦听应答机制。

六,中转BP配置目标时,也是将队列以普通队列相返的方式配置(SEND,REQ,RECEIVE,ANS)。。这样负负得正。队列消息得以通畅。

七,目标队列上,对于BPXP答兴趣的队列,进行正常的侦听应答,无须特别配置。

当然,以上的思路可能是错的,,但只要一个一个审配置,就更容易记得。

时间: 2024-07-29 13:20:41

一点BPXA的思考的相关文章

关于MultiDex方案的一点研究与思考

背景 产生65535问题的原因 LinearAlloc问题的原因 Google提出的MultiDex方案 MultiDex实现原理 缺点 美团的多Dex分包动态异步加载方案 多Dex分包 异步加载方案 参考资料 关于我 背景 目前来说,对于使用Android Studio的朋友来说,MultiDex应该不陌生,就是Google为了解决『65535天花板』问题而给出的官方解决方案,但是这个方案并不完美,所以美团又给出了异步加载Dex文件的方案.今天这篇文章是我最近研究MultiDex方案的一点收获

设计模式的一点总结和思考(一)创建型

面向接口编程 对于当前不知道或无法确定的东西,我们就抽象它,只对其接口操作,即现在不知道具体的涉及对象,但我知道如何使用它,先用其接口,待以后知道了具体的对象之后,再绑定上即可,这就是所谓的封装变化. 虽然不确定目标是谁,但可以确定如何使用目标. 多种多样的设计模式其实做的就是 封装变化 ,面对不同的情景,分析什么是变化的,什么是不变的,封装变化,使上层代码能够"以不变应万变". 简单工厂 [严格来说其并不算是一种设计模式,其就是把一堆判断创建的语句放在了一个函数中,通过传入的参数决定

一点困惑和思考

在学习c++中,a+=b,那么就同等于a=a+b 但是在python中是否如此呢. 所以就有了 a=[100] a=a+a #此时a=[100,100],但不妨思考一下,地址还是最开始a的地址吗 于是有了我尝试的以下代码 1 a=[100] 2 print(id(a)) 3 4 a=a+a 5 print(id(a)) 6 7 b=[100] 8 print(id(b)) 9 10 b+=[100] 11 print(id(b)) 然而得到的结果却是 3071558316 3071558444

程序开发与需求分析的一点疑问与思考

静静的坐在出差归往西安的火车上,想着工作以来程序开发过程中的磕磕绊绊,总觉得不入其法. 并不是编程技能得不到提升,而是程序开发出来与甲方领导的想要的相差甚远.虽然做了很多工作,可领导关心的往往却没有做或者没有达到领导想的那样.在冥思略想之下,这也许就是沟通不到位,需求不到位的恶果.有人可能说,那你去沟通啊,去做好需求啊!哥,我也想啊,可人家领导忙的很呀,只能通过领导讲的大概,自己去琢磨.也许该读读项目管理方面的书,技术在牛逼,连需求都不清楚,做出来是什么鬼??. 第二个就是专业性.通过几次给甲方

关于职业的一点忧虑和思考

很久以前在知乎上看过一个问答,对比几十年前,有哪些消失的职业 当时看了几个答案就挺感慨,今天在路上又想起来一个.在大约20多年前的时候,收水费和查电表绝对是个好职业,挨家挨户去转着看一眼多少字了,收收钱.基本不会特别辛苦. 但今天早上的时候才意识到这个职业真的要快消失了,现在电卡都已经是远程上网的,水卡的改造据说也在进行中.将来所有人都可以在支付宝或网上直接购电购水,那既不需要上门查表也不需要上门收费. 现在想想其实职业变迁还是非常频繁的,如何才能识别哪些是会被淘汰,哪些不会呢? 1. 从事一些

进一步对泛型集合的思考

一.前言: 经常听师哥师姐们说底层这个底层那个,从没见过这个"底层".后来师姐就在项目中应用了这个底层类库,从听说它到自己亲自用它,才发现它还真是强大的不得了啊!经常跟着师哥师姐们的课听,就是想跟这个底层混个"脸熟".我也经常是不懂装懂,其实真正听懂的也没多少啊..不仅脸熟了,还脸皮厚呢.. 言归正传为什么又提起泛型集合了呢?第一次接触是在机房重构的时候,Data Table转换成泛型集合.后来敲这个系统的时候,看到封装的类库中绝大多数的返回结果都是泛型集合.委托和

关于Java并发编程的总结和思考

编写优质的并发代码是一件难度极高的事情.Java语言从第一版本开始内置了对多线程的支持,这一点在当年是非常了不起的,但是当我们对并发编程有了更深刻的认识和更多的实践后,实现并发编程就有了更多的方案和更好的选择.本文是对并发编程的一点总结和思考,同时也分享了Java5以后的版本中如何编写并发代码的一点点经验. 为什么需要并发 ??并发其实是一种解耦合的策略,它帮助我们把做什么(目标)和什么时候做(时机)分开.这样做可以明显改进应用程序的吞吐量(获得更多的CPU调度时间)和结构(程序有多个部分在协同

关于个推的一点想法

最近项目中用到了个推做推送,关于个推的接入步骤官网有很详细的步骤,这里不说,不过正是由于使用个推,引起了一点其他的思考,那就是个推是怎么做到即便把app应用进程在后台杀掉,也能接受到消息. 说到这个问题,先说一个我日常时候android app的一个体会,我们经常打开某一个不常用的应用,打开的同时会弹出很多这个app和其他不常用app的推送消息(注意是其他且不常用的app).为什么呢?因为好多推送平台都使用了一个叫"看护联盟"的东西. 个推官网上说,个推的sdk可以在后台常驻且不会耗费

小规模软件开发团队现存问题思考若干

小规模软件开发团队现存问题思考若干 这里指的是创业初期的软件开发团队,由于面临较大的财政压力,不得不接一些外包来养活自己,然后再抽时间做自己的软件或平台的小规模创业团队.本文系自己的一点浅显的思考,观点较为浅薄,如果存在错误的地方,还望有经验的大神们指正. 一.创业初期的软件开发团队,大多存在以下几点问题: 1.没有产品经理: 没有产品经理,导致软件系统架构设计过于随意,而且项目人员搭配不均衡,最终导致存在以下几个详细的问题(1)设计思路不一致(2)软件流程不一致(3)各终端与后台字段命名不一致