@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.aygfsteel.com/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!