@liyh
这么配置没什么问题，每个server上可以配置多个指向不同db的data source
@zz
1: domain-configuration-JTA
2: 报什么超时？ 事务超时还是thread stuck? 事务超时的话，你的看看每个操作耗时多少，找出性能瓶颈点，找不出来的话，只能加大tx timeout。 Thread stuck的话，做thread dump,看看thread挂在什么地方。
3：weblogic没有这个层面的限制，两个jvm之间可以任意通信，安全限制要在业务层面控制
4：没有这样的例子，呵呵
@zz
1:交易超时可以通过transaction timeout控制，这个超时可以是服务器级别的，也可以是指定服务级别的。
2：应该是Cpu个数*80，这只是个推荐值，实际应用以压力、性能测试结果为准。
3：不是很理解你的问题，rjvm间没有具体的安全机制，需要通过jndi、业务层的sec policy对业务进行保护。
这不都是形势所逼嘛，实在是找不到合适的人啊。
看在俺辛辛苦苦之前发帖的份上，管理员原谅俺一回吧
没错，正如我文中所说的那样，pinned-to-thread被check后，连接一直被某个线程拿着而不会再close后释放。至于用不用这个选项，看应用啦！
re: weblogic92连接池的连接数异常问题 走走停停又三年 2009-09-16 08:02
@gan
这几个参数跟集群没什么关系，这些值由你的应用对连接的需求决定。如果数据库端对并发连接没有什么限制，最后把initial和max设成一样，这样连接池不用在运行过程中去做扩展。
@sorcerer
你可以这么认为，如果费用不吃紧可以考虑lvs。failover是由weblogic的session replication实现的，这个是硬件层面无法做到的。
对于无法连接的server，apache会做mark bad。过了max skip time后，这个server会被重新加入server list（无论这个server是否存活），然后尝试创建到该server的连接，如果失败，那么继续将其mark bad。至于，hanging server的问题，参考WLIOTimeoutSecs。
不要太拘泥于定义。所谓TI，说白了就是工具接口，没必要把要什么语言定义死吧，要这个语言写就是，换个语言写就不是。也许你是对的，TI用c或c++写，而JDI，其实就是TI的高层接口，对于Java程序员更为适用。两者的功能区别有多大？ 他们的功能都依赖于JVM开放函数，即jmvti.h中的函数。你用TI要限于这些函数，而JDI就是对这些函数的封装，我不觉得会少多少东西。至少我们常用的：heap遍历、class装载、卸载监听、方法调用监听、锁等待监听等一一都有。至于类动态更新，你可以看看：
http://www.blogjava.net/fjin/archive/2009/09/11/294634.html
对，线程不会被结束，等同于thread.interrupt()
你手里有TI的例子吗？我对这块比较感兴趣，如果有能否共享一下？ 你说的是agent吧，我这里用的是JDI，TI的Java接口。
Tools can be written directly to JVM TI or indirectly through higher level interfaces. The Java Platform Debugger Architecture includes JVM TI, but also contains higher-level, out-of-process debugger interfaces. The higher-level interfaces are more appropriate than JVM TI for many tools. For more information on the Java Platform Debugger Architecture, see the Java Platform Debugger Architecture website.
参考这个链接：http://java.sun.com/javase/6/docs/platform/jvmti/jvmti.html
对于系统时间问题，我们可以用下面的小程序测试一下，
public class JVMTimeTest {
public static void main(String args[]){
JVMTimeTest test = new JVMTimeTest();
test.retriveTime();
}
private void retriveTime(){
long previousTime = -1;
while(true){
long currentTime = System.currentTimeMillis();
System.out.println("currentTime is: " + currentTime);
if(previousTime > currentTime)
System.out.println("OS time change is detected! and:" +
"previousTime: " + previousTime + " " +
"currentTime: " + currentTime);
previousTime = currentTime;
try{
Thread.currentThread().sleep(100);
}catch(Exception e){}
}
}
}
什么样的runtime exception呢？ 有可能是你的acknowledege可能由于网络问题没有发过去，导致message处于receive，所以不会重新发送。建议你用client_acknowledge，等你消息成功处理后直接调用message.acknowledge()。
你把$DOMAIN_HOME\servers\$SERVER_NAME\data\store\default下的.dat文件备份到其他地方，然后删除他们，重启服务器看看。
172.20.1.18:7005这个url和你当前的AdminServer4Smejb地址、端口一致吗？ 如果一致，172.20.1.18:7005目前通吗？
赫赫，我只是把学到的东西纪录在这里，方便的时候回头看看，温故而知新嘛。
这个问题基本很难重现，原因很可能跟系统环境有关系。weblogic在JMSSession中计算timeout的时候，参考了System.currentTimeMills()，如果系统起了NTP client定期做时间同步的话，可能会在计算的时候引起负值。如果真跟系统时间有关，那么最好的做法就是保证客户端运行期间，不要做系统时间同步。
另外一个客户端回避的方法就是客户端使用receiveNoWait()来代替receive()或receive(long timeout)。
检查一个server log，看看是multi cast有问题，还是managed server本身出了问题。通常情况下，如果server正常，log中你可以看到join cluster之类的文字
的确，并行写文件不如预期的那么快，但相对于串行，大概还是有50%的提升。我做了一个测试，写10个25M的文件，串行要82秒的时间，而并行的每个线程不到53秒。结果如下：
singleThread writer takes: 82.328 secs!
multiThread writer takes: 51.016 secs!
multiThread writer takes: 51.5 secs!
multiThread writer takes: 52.047 secs!
multiThread writer takes: 52.453 secs!
multiThread writer takes: 52.531 secs!
multiThread writer takes: 52.781 secs!
multiThread writer takes: 52.828 secs!
multiThread writer takes: 52.844 secs!
multiThread writer takes: 52.86 secs!
multiThread writer takes: 53.219 secs!