没听说。清华一直是我们的合作伙伴和对手。我参加了清华易程公司的一个高铁售票项目，想替换铁科院的，系统设计是更加合理，也曾在沪宁线试运行一段时间，最终因胡总下台而告吹。
这个设计是采用ORACLE数据库（这就比SYBASE有了质的提高），RAC架构。三层服务，采用TUXEDO中间件。TUXEDO是一个著名交易中间件，现已被ORACLE收购。它采用进程池方式，比铁科院的直连方式有了质的提高，池避免了进程频繁打开关闭，也提供了并发度控制，多机多进程的负载均衡和容错机制。也能承受一定程度的ddos攻击。由于铁科院不愿意认真配合，该系统在与普铁共享席位时极其不顺畅。
除了进程池，TUXEDO没有提供任何其他连接池机制。它的工作原理是有一个监听器接受客户端请求，挑选一个合适的服务器进程，路由再定向到该服务器，客户端与应用服务器是直接连接，不是转发器转接的。服务完成后，用消息队列通知监听器。优点是多进程，崩溃一个不影响其他。缺点是，虽然数据库不再暴露于客户端，但是依然直连应用服务器（就是说，服务器ip地址暴露于外），黑客还是有机会的。
开发中的一个困难是，接受函数调用时自定义buffer尺寸，收发双方难以协调包大小。另一个问题是它只支持无状态服务，就是，一个调用必须完成一个交易，再次发出调用就不一定是原来的进程了。中间状态无法保留。
而我们的交易管理器，是支持有限的有状态交易的，比如发出一个存储过程调用，回来一个游标，再用这个游标进行一系列的fetch，最后关闭游标，全部作业完成，自动通知沿途交易管理器和最终的服务器，归还数据库连接，通知沿途各交易管理器归还连接，结束事务。
也可以发出begin调用，通知沿途及终点，保持所有连接资源，直到commit或rollback。
所有保持连接的状态由客户端计数器控制的，计数器归0发出断联通知。
如果长时间没有动作也不要求断联，各节点会在一定时间后自动rollback，归还连接。
【 在 callmebbser 的大作中提到: 】
: 十几年前，12306卡到死的时期，水木内外民间还搞了个12306NG，下一代12306，
: 希望能走出一个下一代12306的技术之路来。
: 不清楚后来这个12306NG走到哪一步。
: ...................
--
修改:ylh1969 FROM 221.221.55.*
FROM 221.221.55.*