下午，本以回酒店，休息了出去吃东西，结果电话，另外启动的项目，我们作陪吃饭。

一圈下来，喝了不少酒，熏然。回来趴床上就睡着了，半夜渴的不行，起来找水喝，原来电脑还没关，发出莹莹绿光，贼吓人的说。要一睁眼看见yanzi那不就傻了。，让丫从很早前就开始早绿光呢。

想到这，一高兴就睡不着了，俺就小富即安的心理，很容易自己给自己满足。然后就天马行空的乱想咯

想到给FP说的一个笑话：

关于小蛇的，复述一次：

小蛇问妈妈，妈妈妈妈，我们是不是有毒啊。然后妈妈回答，说，是呀，怎么了？小蛇就开始哭了，说，我刚才咬到自己的舌头了。

乱七八糟的想法，发现自己喝酒会思维贼活跃，想到很多很好的东西，但是很遗憾，就像做梦一样，知道貌似有那么一回事，但是清醒后，啥都记不得了，又变成一个普通的人。

很多时候，我都会咬到自己的舌头。

然后钻在牛角尖出不来，跳出来看看小蛇，多可笑呢！

对什么东西希望越高，好像失望就越大。下载到一球成名（2），贼激动，半夜不睡觉，把它给看完了，看完的时候，毫无感觉，比看机器猫和加菲猫，甚至比不上看猫和老鼠的感觉。又一部商业制作，尼采一下。

第一部里面的东西，从纽卡斯尔俱乐部的经理，到教练，到球员，父亲，弟弟，奶奶，甚至是那城市的样子，我都粉喜欢。我甚至很喜欢俱乐部经理的这种老者，我觉得他和阿甘的老妈一样，让人很感动，并且他也说过一些意味深长的话，当然，还有开大奔的格兰，一个年长的球员，对于新人的努力让人感觉很暖和。就像穿着毛衣。甚至里面响起的音乐，都是那么的有感觉。

第二步算起来是小贝的宣传之作了，看宣传，都是这样写的，贝克汉姆什么什么之作，让人不大理解。不说也罢不说也罢。不在追逐这部电影了，失望太多。

里面消失了温厚的长者（俱乐部经理），换来的是一个不苟言笑的老头，我不知道这个人是不是实际上的教练，但是很明显，我不喜欢他。连格兰都让炒了，故事说明了什么？让那些本来好心的人不在去帮助那些需要帮助的人么？故事的情节让人觉得很烂，超级烂。有钱，翻脸不认人，买名车，住大房子，结果如何呢？

格兰说，你自己解决吧，孩子，你已经解雇我了，并且我不会在管你了。因为在那些强硬的词语之后，男主角居然没有给格兰道歉。只是到最后的无助，才有所反省。

人一辈子真是这样的吗？有钱了就翻脸，还是就像格兰所说的，孩子，要保持清新，胜利来的太快，别让它冲昏了头脑。只是到最后陷入窘境的时候，人才懂得反省自己？

原来批评和自我批评是用在这里的，深有所感。

此次使用的版本是53，在52上面发现的。

eos提供一种做法，是!=等同于<>  .这个在设置线上条件的时候经常碰到。

但是在查询的时候，这个就不会等同了。

我对EOSORG_T_Employee这个系统自带的表格使用查询生成向导。

<input type="hidden" name="EOSORG_T_Employee/orgID/criteria/operator" value="&lt;&gt;">

<input type="hidden" name="EOSORG_T_Employee/orgID/criteria/operator" value="<>">

出来的效果和使用

<input type="hidden" name="EOSORG_T_Employee/orgID/criteria/operator" value="!=">

完全不同，使用<> or &lt;&gt;，就和没有使用是一个效果。

为什么呢？理论上来说应该是一样的才是。

这是个问题。

周一到周二，整整2天。和金格的技术人员讨论和制作他们ocx控件和我们平台的集成，当然，这里不是批评金格的技术人员，不用心，等等，但是我想，还是很久以前说的那个话题，不做就不做，做就要做好，要不然会做坏自己的名声的。

首先，对于他们硬件的不理解。db282的服务器，tomcat的应用服务器，居然是跑在一台IBM的T23上，拜托谁行行好，T23是什么时候的配置？在手托盘的地方，有一个很大的标签，intel inside ，PIII，所以大部分时候我都是在等待他的调试，到最后我实在受不了了，只好出让自己的笔记本让他老人家快点搞定，否则按照目前的这个状况，2天能完成数据的增删改查就谢天谢地了。咱公司的笔记本好歹也还是双核1.6，1G的内存。就这样有些时候我还嫌它反应太慢，要是给我个T23，不能想像。

平均每15分钟一个电话，从发货，打款，查账，技术指导，技术咨询。当然，以上属于偷听所得。写程序每15分钟打断一次想其他的问题，效率可想而知。我真郁闷，难道老一辈的没有做上管理层的程序员就是这样的？这样，本来只需要6个小时搞定的问题，折腾了2天，16个小时。并且2天，有一整天我在陪着他调试，他居然不会用eclipse，并且写代码一直用记事本的，连UE都没有。果然是传说中的高手。传说中，高手都不用ide的，都是用记事本写程序的。

还有一点，也是最郁闷的一点。他们的产品的一个附带的文件，封装了一个request的对象的东西，居然不提供源码，你ocx不提供源码我能理解，毕竟我们eos也不提供核心源码的，但是我们pso出去给别人支持，做些项目的时候，你说要是写个java文件，就给别人class，别人会不会发疯？丫的，真过分。搞得eclipse没办法调试和他们相关的东西。

等这个项目差不多了，不是那么忙的时候，上sf找个开源的在线office，其实就要一个在线的word，集成到我们的eos里面去，是很有必要的一件事请。lilin说，等到东莞做oa的时候，就用我们自己的控件，1人收费1w。，哈哈，这个可以考虑考虑。在公司如果想突破，金融，电信我是没啥希望超越公司的前辈了，只好在OA上想办法了。

事务很容易产生bug。这是一个问题。

在广州的时候，出现的bug是集群的事务不同步，而这次在佛山出现的bug，是多数据源的问题。先说一下整体的情况。

OA系统，用到我们EOS作为整体框架，websphere5＋db2 8.2 + EOS ，eos的版本号为52。用到了多数据源。

理论上来说，一个事务操作一个连接，所以在整个事务中间，如果需要用到另外一个连接，自然会报错。

比如在广州的时候，一个bizlet用到这段代码：

ProcessCaller pc = new ProcessCaller("common", "0", "-1","defaultAppID")

看上去，只是new 一个 ProcessCaller，没什么大不了的。但是实际上，请跟踪他的连接，会发现，他自己会new一个连接。如果这个时候你用调用该bizlet的事务里面的数据，当然，会拿不到里面的数据了。

而这次出现的问题是：

一个prP的事务里面，调用一个biz，bizA的数据源设定是A数据源，而biz里面的biz bizB里面，设定的是B数据源。这样有一个层次的关系。

prP事务>bizA>bizB

当prP事务调起bizA的时候，根据bizA的配置，默认的拿到A数据源，所以这个时候，增个事务是针对A数据源的，而在bizB里面，需要操作是拿到B的数据源，对B数据源对应的表进行操作。由于之前事务已经有一个数据源，这个时候，B数据源在该事务中是拿不到的，所以就会把错误抛出。

很明显，这个错误很正常，如果用到spring的事务，也应该会遇到这个问题。本来逻辑上，这样就是说不过去的。

该怎么解决？

update:

最后的解决方案，在bizB的里面，再次封装一次，封装的biz的属性里面获取另外一个连接的数据源，这样就可以了。对于     如果用到spring的事务，也应该会遇到这个问题。 这句话，可能是有问题的，嘿嘿，chengzhi说，XA的数据源是能满足这个要求的。

，小子无知，大胆猜测。