冲动是魔鬼

WLS支持在Global transaction中存在最多一个非XA的Datasource，这就决定了在同一个Tx context下，Datasource.getConnection必须保证总是从ConnectionPool中选出相同的物理连接，不过从JDBC规范来讲，这件事应该是不需要被保证的。

官方声明

http://edocs.beasys.com/wls/docs81/faq/jdbc.html

Q. If an application calls DataSource.getConnection multiple times in the same thread and transaction, will WebLogic Server handle giving me the same connection and transaction?

A. A common scenario might be to have multiple methods that are called within a transaction (begin/commit) that do something like the following:

Context ctx = new InitialContext();
DataSource ds = (javax.sql.DataSource) ctx.lookup("connpoll");
// work using Connection

In this case, all of the work will be done within the transaction and the same underlying JDBC connection will be used as long as the DataSource ds is a tx data source.

按时间顺序描述如下：

 

1.2008/7/23号起从我的笔记本上无法登陆windows live id: zhu_da_zhi@hotmail.com

         zhu_da_zhi@hotmail.com的密码类似于Aaaa0000

 

2.发现如下面事实

        a.在同样的hp内网中的另一台机器上有时可以登陆，有时也不可以登陆。

        b.在同一台机器上使用其他live id可以登陆。

 

3.鉴于1的问题无法解决，所以申请了一个新的live id: zhudazhi@live.com，可以正常使用

         zhudazhi@live.com的密码类似于aaaaaa

 

4.当把zhudazhi@live.com的密码改成Aaaa0000时，zhudazhi@live.com也变的不可登陆

 

5.于是自然而然的推测把zhu_da_zhi@hotmail.com的密码改成aaaaaa时，将可以解决1的问题

   事实说明，此想法正确。

 

虽然还有些其他线索，不过主要动作就是这几步，这件事情以我的脑袋实在是连猜测都无法猜测有

哪些可能性。不知道是symantec IM manager搞的什么名堂还是我本机软件有问题。

gem install很奇怪，对-p参数认识，但又没正确处理对，导致在内网中使用proxy的人无法安装gem，好在可以指定环境变量，set http_proxy=http://xx.xx.xx.xx:yy

今天nav老是报发现木马，名称是comaddevent.dll,开头在看程序没注意，刚才看了一下，它使用了4个service侵入系统

AutoUpgrade

Background Intelligent Transfer Services

COM+ Event System Helper

DNS SystemServices

 

而系统真正负责这4件事情的是

Automatic Updates

Background Intelligent Transfer Service 

COM+ Event System 

DNS Client 

 

这个病毒故弄玄虚的在每个Service的注释里面都提醒用户不要禁止我哦，而且Service实现程序里面把stop,pause都停用了，所以只有进入安全模式，去删HKLM/System/CurrentControlSet/Service下相应的node和system32下相应的dll,目前来看写病毒的人还算客气，除了安装这几个Service外，还没有变态到去做Hook恢复这些Service。