2009-10-28 27 views
2

我們有一個J2EE應用程序,我們仍在其中工作。它運行在Oracle DB上。並且業務層使用具有豐富客戶端界面的EJB 2.0進行編碼。在j2ee應用程序中的站點之間複製數據

現在,應用程序將部署在多個站點上。並且每個網站將創建新項目(新合同等)。

我們要明白什麼是重複添加到使用相同的數據庫架構作爲本地的中心位置,數據庫中的所有新項目。

您認爲最有效的方法是什麼?

我想過序列化的所有新項目創建,將它們發送到遠程站點,通過Java消息服務隊列的集成。這種方法好嗎?

而且還會有一些變化被複制回衛星。

回答

2

我想說,與中心的同步關係會引入你不想要的耦合。因此,你的異步想法對我來說似乎很好。您可能在記錄中有一些與位置相關的標識符,以便不同位置的新合同創建不會發生衝突,並且您在接受中心複製時會接受一些延遲。

所以最簡單的情況是,只要使用從每個位置到中心的JMS消息。

這個appraoch的好處是,顆衛星甚至不需要知道在中心數據庫結構,它可以完全idepedently設計。

如果您還需要將更改從中心複製回衛星,事情會變得更有趣。最大的問題是我們是否會在中心的變化和衛星的變化之間發生衝突。

簡單情況:任何數據項有一個「家」。例如,起源衛星是改變的地方。或者在創建之後,中心是ti進行更改的唯一地點。在這種情況下,我們可以將中心視爲「中心」,它可以將改變傳播給衛星。簡單的JMS可以做到這一點。

稍硬的情況:可以在任何地方進行更改,但一次只能在一個地方進行。因此,如果鎖定方案我們可以引入somne​​類。我傾向於將中心作爲所有者,並使用同步Web服務來鎖定和更新數據。現在我們聯繫起來了,但如果我們要擁有一個明確的擁有者,這是必要的。

相當複雜的情況:任何人都可以在任何地方改變任何東西而不鎖定。這是一個「先行動,後道歉」的方法。我們採取樂觀的態度,改變不會發生衝突。我們可以將更改發送給中心,中心可以使用樂觀鎖定或合併非衝突更改方法。我傾向於通過排隊更改發件人,但實際上通過同步調用來處理它們。因此,從中心的可用性中去掉變化的規範。一些更復雜的數據庫具有差異/合併功能,可能有助於此。

大問題是在何種程度上要連接到中心的可用性和衝突的更改的可能性其中。狡猾的應用程序設計經常會大大降低衝突的可能性。

+0

一些變化肯定需要從中心複製到衛星。你打算如何處理? – Attilah 2009-10-28 08:48:28

+0

我會更新答案 – djna 2009-10-28 08:58:56

相關問題