走自己的路

路漫漫其修遠兮，吾將上下而求索

BlogJava :: 首頁 :: 新隨筆 :: 聯系 :: 聚合

:: 管理 ::

50 隨筆 :: 4 文章 :: 118 評論 :: 0 Trackbacks

Java Persistence, Transaction and ORM

java持久化事務管理和 OR Mapping

偵聽和處理用戶對業務對象改動的簡易框架

摘要: 在用戶修改了領域對象的值后，我們有時需要記錄下用戶的改動。比如對一些關鍵業務對象的改動有時往往需要發郵件通知客戶。有時用戶可能想查閱所有歷史的改動，甚至有可能會改回原先的值。領域邏輯關系往往比較復雜，這時我們會使用到ORM Framework。本文以toplink為例，講述如何利用toplink編寫一個完成此功能的簡易Framework，我們暫且把它稱為ActionMemed。
閱讀全文

posted @ 2009-11-29 13:37 叱咤紅人閱讀(1453) | 評論 (2) 編輯

Oracle應用服務器單個Container多Process(jvm)環境下，用Ormi和jms實現toplink會話緩存同步

摘要: 在Oracle Application Server環境下OC4J Instance下的每個process的jvm的rmi端口是動態分配的，如果能解決這個動態的問題，就可以使用ORMI作為jndi的provider url。但是需要注意的是如果是在server啟動時初始化toplink session，需要等待JmsServer線程執行完畢。閱讀全文

posted @ 2008-12-09 18:00 叱咤紅人閱讀(1291) | 評論 (0) 編輯

opmn和jms實現toplink session緩存同步的解決方案

摘要: 在分布式應用中，單個業務應用的toplink運行在多個jvm上，同時開啟了會話緩存，而這些在多個jvm上會話緩存中的domain對象就需要進行同步，這樣可以及時拿到最新的domain對象而不需要每次都查詢database，這大大減少了樂觀鎖沖突。在Oracle Application Server上Ormi端口是動態分配的，而opmn request端口氏固定的，所以我們用opmn作為jndi lookup的url。經過測試OC4J in memory jms作為同步消息的傳輸和發現方式效率是最高的，所以采用OC4J in memory jms作為消息同步的傳輸方式。具體實現方法參見本文。閱讀全文

posted @ 2008-12-04 07:00 叱咤紅人閱讀(1238) | 評論 (0) 編輯

oc4j+toplink+spring使用jta外部事務的一點心得

摘要: 晚上要下班的時候，application team那里使用Tibco EMS做消息集成服務時候出了bug，錯誤是：java.sql.SQLException: 當全局事務處理處于活動狀態時, 無法調用方法 'commit'，應該是在全局事務中使用了本地事務并提交了。幫忙看了一下，它的oc4j, toplink, spring的使用上都存在著一些問題，并把要注意的地方總結了一下。包括oc4j，toplink，spring三塊。閱讀全文

posted @ 2008-11-14 21:48 叱咤紅人閱讀(2223) | 評論 (11) 編輯

如何在JAVA端使Oracle存儲過程串行地執行

摘要: 在java端調用存儲過程的時候需要存儲過程串行的執行，如果使用synchronized lock在應用服務器突然down掉的情況下會出現問題，因為session并沒有立即斷掉，后臺的存儲過程還在繼續執行，這樣如果應用服務器立即重啟，再調用該存儲過程或者其他需要一起串行化處理的存儲過程就會違反同步執行的原則，所以我們必須把鎖放在oracle db端，利用oracle鎖機制來完成存儲過程的同步，文章總結了一下在java端如何使用oracle這個用戶鎖機制。閱讀全文

posted @ 2008-08-25 14:12 叱咤紅人閱讀(1812) | 評論 (0) 編輯

Toplink多種會話緩存同步方案的性能比較

摘要: 上次用Coherence實現緩存數據同步的transport manager之后，對它進行了壓力測試并和EMS JMS和 OracleAS JMS（內存）進行了性能對比。文中描述了測試的過程，并共享了代碼和測試結果。閱讀全文

posted @ 2008-06-13 14:46 叱咤紅人閱讀(2404) | 評論 (1) 編輯

用Oracle Coherence實現Toplink Session Cache之間的數據同步

摘要: Toplink提供了很強大的Cache功能，利用cache可以大大減少直接和DB通信的次數，特別是讀事務比較多的情況下。在分布式應用中，多個toplink session cache之間需要即時的同步數據，保證各個cache中的數據都是最新的數據，避免頻繁地出現stale數據或樂觀鎖異常。Toplink默認支持的兩種同步機制：JMS和RMI，有時為了考慮一些特殊的需求，必須性能，我們可能需要自定義一個Toplink的Transport Manager，本文給出了一個用Oracle Coherence實現Toplink Tranport Manager的具體例子，注意只是用了Coherence的通信并沒有把Coherence整合成Toplink的Session Cache。閱讀全文

posted @ 2008-05-24 17:37 叱咤紅人閱讀(2305) | 評論 (0) 編輯

走自己的路

留言簿(7)

隨筆分類(81)

隨筆檔案(54)

文章分類

搜索

最新評論

閱讀排行榜

評論排行榜

Java Persistence, Transaction and ORM