InfoQ: Presentation: Transaction Management Strategies in Mission Critical Applications

InfoQ: Presentation: Transaction Management Strategies in Mission Critical Applications

Juergen Hoeller is one of most respected guru in Java programming landscape. Most of his reputation is duly earned: after all, he co-designed and is still heavily involved in the current Java programming standard framework, Spring Framework.

In Java society, a framework dictates thought leadership. An application framework is, actually, encapsulation of commonly defined best programming and design practices. An application framework like Spring greatly reduced the learning curve of commonly accepted Java programming practices and allowed software veterans to deliver software with increased productivity as well.

OK, now that I have done the praising part, let us begin with a little bashing. In this presentation, Juergen keeps mentioning different Transaction strategies, which is detailed and shows that he indeed knows his stuff, but one of Juergen's remark sounds a little alarming. Juergen seem to dismiss the importance of distributed transactions, saying that XA is needed in very few circumstances.

While I do agree partially on this part, an expert like him should be more careful in not misleading people. While you can certainly say that 90% of Java Web Applications don't need Distributed Transactions, you are misleading people. Because you forgot to mention that the rest 10% are composed of more high profile, and more profitable software projects.

Let me put it in another way. Are we Java Developers competing with PHP guys? PHP doesn't have XA as well, and they are doing just fine. If your software project can be safely implemented by using either Java or PHP, which 90% of time will be the case, then yes, you don't need EJB, and certainly don't need XA. But if you are lucky enough to climb to a strategic position like VP or CIO, you will regret that in your former career you haven't structured your IT systems so that distributed transaction propagation can be enabled.

And you, Juergen, should be fair when you try to dismiss the importance of EJB, XA and middleware. Because you are not ignorant.

The right direction where JavaEE application server should be heading

With commoditization of JavaEE application server market, it's good to see application server vendor finding the right niche.

Finextra: LiquidityHub achieves eight millisecond latency for fixed-income price distributione

WebLogic Realtime and WebLogic Event Server are both designed to meet specific latency problems. Low-latency is an area that was forbidden for Java based applications because of uncontrollable pause time brought by garbage collection, a Java Virtual Machine feature that automatically frees up physical memory and re-allocates it.

So, for first time, low-latency applications can be achieved using Java, a common skill set, and Intel-based Hardware. If BEA executes this strategy well, it can find ways to commoditize upper industry sector that was predominantly an IBM territory. If that's the case, then BEA is definitely worth more than 21 dollars per share.

This also reminds me of a myth: how can some Wall Street analysts decide the value of a certain technology company if they don't know technology well? How such market consensus if reached?


Technorati Tags: bea, weblogic

Powered by ScribeFire.

WebLogic Server: 交易的迷思

一般的程式設計師對於單一資料源的交易處理機制都有一定的了解。所謂的交易控管，用白話文來說，就是只要我需要一次更動多筆資料，而這個更動的行為在邏輯

上是一個具有業務價值的單一行為，我就需要交易的處理機制。但是比較少人花心思去了解的是J2EE裡頭規範Application
Server必須Follow的XA Transaction Protocol以及更具有價值的Transaction Recovery機制。

接下來我想要點出的是一般人的迷思：

1. 迷思：只有在多重資料庫的資料更新場合才需要2PC。事實上只要你有兩個以上的DataSource想要同時參與一個Transaction，你就需要2PC。除非你自行處理所有的交易補償邏輯，否則兩個以上的Local Transaction，是不會有相互關連，資料的正確性也就大大的有問題了。
2. 迷思：只要依賴資料庫的交易機制，我的資料正確性就無懈可擊！
   假設Application Server正在處理一個交易，一個Batch
   update好了。你從DataSource1把資料傾倒到DataSource2，一邊將DataSource1的資料清除掉。這時候，不知道什麼原
   因，網路斷了，或者電源線被踢到了....源源不絕的客服電話把你灌爆。你以為你把電源插上就沒事了，可是.....咦，資料好像不太對？這時候如果你用
   得是WebLogic Server Advantage以上的版本，你可以透過Transaction Log自我恢復的機制，來讓WebLogic
   Server幫你Rollback資料庫裡頭的資料，維護你資料的Consistency。當然，你可以自己花錢花時間寫這個機制....但是你的客戶是
   否可以接受哪怕是幾分鐘的資料不正確？

簡單的結論：除非你的AP只提供簡單的查詢介面，否則你幾乎一定會需要用到2PC以及
Transaction
Recovery的功能。Transaction的問題很難Debug，已經看到太多英才死在這邊了，拜託大家緬懷先列的犧牲，不要再為了這種問題而強制
性失眠了，請愛用XA，謝謝！

Powered by ScribeFire.