谁用过交易中间件吗?

一千年前的人 发布于 2012/04/29 19:47
阅读 2K+
收藏 2

哪位使用过交易中间件的, 例如

IBM CICS, ORACLE TUXEDO 和 http://www.oschina.net/p/tuxone

讲解一下交易中间件原理和开发例子。

我查了一下网上的例子都是基于CS模式的程序用的,主要是金融电信业用的。BS的web程序用的着吗?

另外,交易中间件的原理、使用  与 Java事务API(JTA:Java Transaction API) 类似吗?

加载中
1
宏哥
宏哥

建议你不要研究这个东西,除非你在金融,电信行业. 这些东西是用于复杂事务控制的,跨数据库事务控制,除非你能在工作中用到,否则无法学习,更不肯从OSC获得有价值信息.

至于 JTA,和j2ee一样徒有虚表. 联机事务 == 数据库事务. JTA 不是事务,这个和j2ee不是企业应用一样.

真的要了解事务,从数据库入手.

web 系统都是联机事务(cics/tx)的客户. 所谓的j2ee平台, 在事务当中,是客户,呼叫方.

一千年前的人
一千年前的人
恩, 明白。 我只是了解一下原理就好了。 才不会去实践呢。 谢谢。
0
一千年前的人
一千年前的人
J2EE Web 系统都是 交易中间件cics/tx 的客户端。 J2EE容器自己的JTA算是一个学习玩具吧。
0
宏哥
宏哥

引用来自“一千年前的人”的答案

J2EE Web 系统都是 交易中间件cics/tx 的客户端。 J2EE容器自己的JTA算是一个学习玩具吧。

充其量是个接口. java没有能力控制数据真正读写,事务就和它没有关系.事务就是要写到磁盘才能叫事务,否则断电了还有个屁一致性.

真实环境都是通过 数据库的 commit 或者 rollback来控制事务的.

中间件可以跨多个数据库,甚至多个应用来控制事务.

0
m
muyuan
感觉是这样的,很多的开发当中都涉及事务的概念,其实说白了就是注重一组操作的完整性而已。
这是一种事务(或曰交易)的概念,但是CICS和这个的侧重不同,因为应用的要求特点很不相同。
通常你自己写的交易程序,你很难指望它成千上万个的并发平滑运行。
CICS开发出来的交易却就是这样的,就比如你在银行的存取款操作,实际上这是一个很简单的事务,从Java或任何主流的编程语言角度看,简直太小儿科了。可是它要求的是支持一家银行在全国所有的分行,分理处,储蓄所,甚至ATM机上的操作同时的进行这样的海量并发的“简单事务”,你需要能够平滑稳定健壮的把它处理好,尽管有数千个储蓄所,更多的操作柜台,但是他们所连接的后台主机环境实际上却是同一个,就是在这同一个环境(其实是集群的,大机也是集群的)中,同时处理了无数这样的“短交易”,存款/取款/转帐等等等等,它们在后台访问的是同一个DB2数据库。那上面是数以亿计的客户‘帐户,要稳定可靠绝对的保证数据一致性的海量平滑并发的处理好每一笔独立的业务上的交易(它可能对应了若干的CICS交易),你的Java程序能搞定这样的事吗?
不错,事务的概念就是提供保证交易一致性的手段,当然不能前台看着存款10000元是成功了(没有报错)但是整个处理路径上哪个环节来了个小毛病,然后后台数据库里并没有实际写入这10000元。
你开发的软件系统是要保证在成千上万的这种并发处理的情况下绝对不能发生这样的差错,你怎么保证的了,web程序怎么保证的了?
所以说它不是一个你从功能开发角度看“有什么样的深奥”的东西的概念。

银行核心这样的关键业务系统上,它要的是绝对的稳定可靠的久经验证考验的绝对成熟可靠的方案。
所以说,交易中间件,开源的产品实际上是没有什么意义的了,听说有一个TUXONE是开源的交易中间件,类同于Tuxedo(CICS的对手)
Java开发出来的程序你肯定是不能指望它能有这样的表现了。
Java从其产生那一刻起,它生命的主要意义就不在于此,它生命的最大意义还是在于跨平台
每当用户讲Java慢,Java的童鞋们定然都会奋起反驳,Java运行并不慢,诚然是的,我也同意。
可是我们打个简单比方,这就好比硬盘的传输率和IOPS(每秒IO处理能力)之于硬盘的速度一样。
没错,台式机的硬盘传输率根本不慢,可是作为服务器使用它真的就不行就慢。
这是因为衡量硬盘速度不能只看持续传输速率这一个指标,IOPS在服务上更加重要。
你持续传输速率不慢,可是那只能体现在传输一个大文件上。
当传送的是无数个碎小的文件时,你每个文件的真正进入持续传输前的“准备工作”太过迟缓,对于碎小文件而言你准备传输的时间甚至都已经超过了真正实际用于传输的时间。
这也就是IOPS性能指标不行,表现出来的结果就是当硬盘有读有写还都是碎小文件时(这是服务器的典型负载)你就是慢。
Java就是这样,尽管现在已经有无数的技术来辅助缓解这一问题。
但是它仍然是问题,一个Java程序在真正进入执行之前的准备真正拖了它的后腿,使它永远不能真正的作为后台事务处理的核心。
就像前面某童鞋讲的,这种级别的数据一致性是从数据库角度实现的,当然它是C写的Oralce的数据库肯定不会是Java写的。
而当你要实现复杂一些的应用事务(交易)时,肯定不能由数据库本身来做交易系统(程序都应PL/SQL去写?)了。
这时你就需要有一个完整的辅助环境来帮助你的程序实现前面说的那些关键特性。
你就只能选择CICS,它不能绝对保证你的程序自动就完全具有了那些优良特性。
但是它的整套环境开发调试手段,运行管理手段等等都能帮助你最大限度达到那样的目的。
至少能让你的程序在磨合中迅速无限逼近那样的特性:稳定,交易完整(它叫交易的原子性),海量并发平滑处理
是IBM的软硬件机制辅助你达到这样的目的。

我们这说的其实还只是联机交易处理,还没有涉及到跑批。
要跑批那也是IBM大型机的绝技之一,你在开放平台上,任它是AIX/HP-UX,Linux,或是Windows等等,你想你怎么来保障你打开了一个好几个G大小的文本文件,要逐行处理好其中的每一条内容,也是中间绝对不能出现崩溃。
即使真的出了意外,你也还能从新打开它接着上次失败的地方继续往下处理。
有什么样的可靠的手段来有保证的做好这个么?
这又是从程序功能角度很简单的事情,但是有特殊的要求的场景。
所以IBM大机暂时死不了。
虽然我不搞大机,我其实很多事情都是在推动让IBM大型机彻底尽快推出历史舞台。
但是平心而论,它是有它的优势的,尽管为这一点点优势大家付出了太大太大的代价而已。
看那些专业搞大机的人一被别人问起大机有什么优势就答不上来,甚至开始胡说八道,说大机性能优势。
我听着就觉得好笑。
大机有性能优势?
大机的CPU性能怎么可能像x86遵循摩尔定律那样每一年半就翻翻呢。
那是要上千万上亿的出货量来保证的,小机都不行Power它没有那么大的出货量,它怎么来投入那样的研发,确保每一年半性能翻倍?
所以才会发生今天的PC性能甚至超过了就在不很远的以前的多少年前的大型机的计算能力,甚至iPAD的计算能力都超过了它。
说大机的IO速度快,800年前也许是这样,大机上极其昂贵的FICON,ESCON号称高速的光纤通道,它的传输率是多少?
我都不好意思替他们说了,可人家绝然还在振振有词的讲大机性能优势呢。
当然了,没有绝对的说法,你非要花上一千倍的价钱去买来一台的大机可能也许真的能比你同等价钱的开放平台的x86快上几倍吧。

提起大机我就有气,愿我们大家共同努力提早让它退出历史舞台,让IBM提早退出IT的历史舞台,它可以去做它的管理咨询,它不是收购了普华永道么。
但是千万不能说IBM搞IT厉害,它只是忽悠讲故事厉害。


一千年前的人
一千年前的人
信息量很大,观点很多, 要是分开整理一下就好了。
返回顶部
顶部