/* Author: J@mes */

總結（2）是針對EJB3的事務和安全中的容器管理事務（CMT），BMT及安全部分放在總結（3）中。
完全是自己學習的心得，還請前輩們指點。

 

EJB3的事務與安全

EJB3的是事務也符合ACID，即原子性、一致性、隔離型、持久性。這些特性與數(shù)據(jù)庫事務一致，需要強調(diào)的是一致性，在事務開始前，系統(tǒng)是處于一種遵守業(yè)務規(guī)則和約束的一致狀態(tài)下，那么在事務提交或回滾之后，系統(tǒng)也必須維持這種一致性狀態(tài)。在事務進行過程中不必處于不一致性狀態(tài)，事務在這里就像一個沙箱（sand-box）。

在EJB中，事務也具有隔離級別的控制，但一般不用通過EJB容器來控制，而是在數(shù)據(jù)庫資源這一級別來進行控制。

 

要知道在EJB容器中，代碼層面的所有操作最終都是轉化為兩級的數(shù)據(jù)庫操作，比如鎖定和解鎖數(shù)據(jù)庫中的某行或某張表。事務日志來反映事務的變化，開始事務日志代表事務的開始，應用日志代表以提交該事務來結束，相反放棄日志就代表回滾事務而結束。

 

資源管理器（Resource Manager）的概念是管理特定某種資源的事務的組件。這個概念不僅包括關系數(shù)據(jù)庫系統(tǒng)，也可以使消息服務器或其他業(yè)務系統(tǒng)。

 

如果只涉及一種單一資源的事務就稱為local transaction本地事務，相反大多數(shù)企業(yè)應用都是需要涉及多種不同的資源。這時候就需要一種類型的組件來管理事務中多種資源，這個組件稱為事務管理器（Transaction Manager），它在多個管理各自資源事務的資源管理之間進行協(xié)調(diào)和控制。

 

分布式的事務管理是通過一種稱為兩段式提交（two-phase commit）的機制來完成。現(xiàn)在最為流行的分布式事務協(xié)議是XA協(xié)議（XA Protocol），JavaEE就是通過該協(xié)議來完成分布式應用中的事務管理。

 

事務管理

JavaEE中事務使用JTA（Java Transaction API，是建立在Java Transaction Service之上的服務），即javax.tranaction.UserTransaction接口，容器在后臺會自動管理大多數(shù)事務細節(jié)，EJB開發(fā)者只需控制開始和停止事務、建立事務邊界（transaction boundary）以及是否提交/回滾業(yè)務即可。

在EJB3中提供了兩種具體的事務方式，即容器管理的事務（Container-managed transaction，CMT）和bean管理的事務（Bean-managed transaction，BMT）。其中前者是使用聲明式地或通過部署描述符來管理事務；后者需要以顯式編碼的方式來管理。但需要注意的是在EJB3中，只有SessionBean和MessageDrivenBean才支持CMT和BMT，JPA中并不直接依賴CMT或BMT。但是當然，在任何JavaEE容器中都可透明得插入CMT或BMT的事務環(huán)境。

EJB3中管理事務最簡單靈活的方式是采用容器管理事務，即CMT。

 

容器管理的事務，顧名思義，容器來做“事務開始、事務提交或回滾”。容器在調(diào)用方法前開始JTA事務，接著會調(diào)用業(yè)務方法，最后根據(jù)調(diào)用中發(fā)生的情況去決定是提交事務還是回滾事務。使用CMT事務管理，只需關注@TransactionManagement和@TransactionAttribute注解，同時通過EJBContext的方法來回滾事務。

 

1．@TransactionMangement注解用于向容器標識該bean的事務管理是使用CMT還是BMT，是通過該標簽中的value屬性來指明TransactionManagementType的枚舉值。

 

2．@TransactionAttribute注解，盡管由容器為我們來管理事務的各種細節(jié)，但是仍然需要通過該注解來告知容器如何去自動管理。

CMT對事務的管理可以在包裝bean的方法時開始，也可以從調(diào)用者的事務中進行join開始。

TransactionAttributeType有幾個枚舉值：

（1）      REQUIRED：如果調(diào)用者沒有事務，容器則創(chuàng)建新事務；如果調(diào)用者具有事務，容器則連接join調(diào)用者事務。

（2）      REQUIRED_NEW：如果調(diào)用者沒有事務，容器就創(chuàng)建新事務；如果調(diào)用者有事務，容器暫停原來事務，并創(chuàng)建新的事務。

（3）      SUPPORTS：如果調(diào)用者沒有事務，容器就不創(chuàng)建事務；反之則join并使用調(diào)用者的事務。

（4）      MANDATORY：如果調(diào)用者沒有事務，容器拋出javax.ejb.EJBTransactionRequiredException異常；反之則連接并使用調(diào)用者的事務。

（5）      NOT_SUPPORTED：如果調(diào)用者沒有事務，容器便不使用事務調(diào)用方法；反之則暫停調(diào)用者事務以non-transactional的方式調(diào)用方法。

（6）      NEVER：如果調(diào)用者沒有事務，容器直接調(diào)用方法；反正拋出javax.ejb.EJBException異常。

 

a.    對于第1種情況，適合的場景是從non-transactional的Web層調(diào)用bean方法，如果方法調(diào)用出現(xiàn)異常，那么容器不僅會rollback整個事務，同時也會向調(diào)用者拋出javax.transaction.RollbackException異常，以通知調(diào)用者事務已被回滾了。

b.    第2種情況中，始終需要容器去創(chuàng)建新的事務，對于調(diào)用者原有的事物，容器就會暫停它，直到方法調(diào)用返回為止就恢復原有事務。這樣的結果就是方法調(diào)用所創(chuàng)建的新事務無論成功與否，都不會對調(diào)用者原有的事務造成影響。

c.    SUPPORT選項表示本質(zhì)上容器將會按照調(diào)用者的事務情況來處理，通常的場景是用于一些只讀型的操作，比如檢索數(shù)據(jù)記錄等。

d.    MANDATORY表示對容器對事務的強制性要求，如果調(diào)用者存在事務，容器就join并使用調(diào)用者事務；但如果調(diào)用者沒有事務環(huán)境，就會拋出EJBTransactionRequiredException異常。這種選項適合于如果方法調(diào)用失敗進行回滾時也保證調(diào)用者環(huán)境的失敗。

e.    對于NOT_SUPPORT，容器處理的本質(zhì)是要求不能在事務環(huán)境下調(diào)用bean方法。如果調(diào)用者存在事務，容器會先暫停它，然后開始方法調(diào)用，在返回后恢復調(diào)用者的事務。

f.    NEVER表明在CMT中，容器不能允許從事務性環(huán)境中調(diào)用bean方法，否則會拋出EJBException異常。

 

對于前面這六種TransactionAttributeType，MDB并不是全部都支持，它支持REQUIRED和NOT_SUPPORT兩種。這一點與MDB的特性有關：客戶端無法直接調(diào)用MDB，所以事務屬性中的SUPPORT、REQUIRED_NEW和MANDATORY就沒有意義。

CMT事務管理的真正機制

很重要的一點：CMT方法要求容器回滾事務并不是立即進行的，而是向容器設置回滾標識，在事務結束的時候，容器檢查該標志，如果不需回滾則提交該事務，如果需要回滾則進行。

通過EJBContext或其子類：SessionContext和MessageDrivenContext的setRollbackOnly()方法，將回滾標志位置為true，當方法調(diào)用結束時，容器檢查該狀態(tài)以判斷是否提交事務或是回滾事務。

需要注意的一點是，本質(zhì)上，使用EJBContext進行設置標志位時，它是作為底層事務的一個上層抽象代理。所以使用時，必須保證有底層事務存在，也就是說必須在REQUIRED,REQUIRED_NEW,MADATORY這三種事務屬性下使用！因為這三種事務屬性都可以使容器保證底層事務的存在，即無論方法調(diào)用者是否存在事務環(huán)境，容器都會創(chuàng)建新事務。

與setRollbackOnly()方法對應的是getRollbackOnly()方法，該方法返回當前EJBContext中回滾標志位的狀態(tài)。該方法在業(yè)務處理中十分有用，考慮這樣一個場景：

在進行一段非常長的資源密集型操作前如果前事務的前部分已經(jīng)失敗，那就是在一個注定要回滾的事務上付出很多代價。所以在這類操作之前應該先check一下rollbackOnly是否已經(jīng)置為true。

此外，處理該標志位狀態(tài)的代碼經(jīng)常分布在業(yè)務邏輯的catch塊中，如果catch了某種exception，則一邊記錄進log，一邊通過set方法置狀態(tài)位。在EJB3中，可以通過@ApplicationException注解使得“捕獲異常轉化為事務回滾”變成透明的機制。

@AplicationException注解

@javax.ejb.ApplicationException該注解可以用來控制事務性輸出，將要拋出的異常類型在定義時加上該標簽，同時設置該標簽的rollback屬性，即@ApplicationException(rollback=true/false)。應用異常（ApplicationException）是希望調(diào)用者或客戶端處理的，一般認為除了java.rmi.RemoteException和java.lang.RuntimeException之外都是應用異常。而從上述兩種異常繼承出的子類異常都被認為是系統(tǒng)異常，這種異常不會傳遞給調(diào)用者或客戶端而是wrapped在EJBException中。

添加此注解的異常無論是checked exception還是unchecked exception（比如運行時異常），都會被認為是應用異常（application exception），從而傳遞給方法調(diào)用者或客戶端。

默認情況下，所有checked exception或所有被注解為應用異常的checked/unchecked exception，都不會以CMT的方式回滾，如果把rollback屬性設置為true，則會通知容器失敗時進行事務回滾，并且是在把應用異常傳遞給調(diào)用者或客戶端之前進行的。

如果有未預料的unchecked exception，比如ArrayOutOfBoundsException或NullPointerException，容器仍然會回滾CMT事務，但是在這種情況下，容器會認為bean處在了一種inconsistent的情況下，會進而銷毀bean實例，這是十分消耗資源的，所以you should never delibrately use system exceptions.

 

CMT使開發(fā)人員不必關心EJB事務中的大部分細節(jié)，當然同時CMT能提供對事務的控制級別也更少，這一點Bean管理的事務（BMT）更適合。

 

作為近期學習EJB3  的一些心得和總結，完全是自己的理解和白話，前輩們請多指教

EJB3學習總結（1）

現(xiàn)狀

EJB2得到了較廣泛的應用，但真正用對場合的項目不多，那些強調(diào)分布式，即業(yè)務邏輯和Web是在分布在不同物理層的大型項目。更多得是使用在中小型web應用之上。

EJB3在Spring、Hibernate等一系列輕量級框架運動的發(fā)展后現(xiàn)身了，EJB3是基于POJO組件的，同時提供了事務、安全、ORM和分布式等諸多特點，同時AOP、DI及Annotation等特性也進一步提高了EJB3的易用性。

EJB3規(guī)范

EJB3規(guī)范包含3個技術文檔：

1.       EJB3 Simplified API

2.       EJB3 Core Contracts & Requirement

3.       Java Persistence API

EJB3組件模型

1.       Session Bean：執(zhí)行業(yè)務服務、控制事務及資源訪問

2.       Message Driven Bean：異步調(diào)用，通過JMS關聯(lián)消息隊列（Queue）及Topic來響應外部事件

3.       Entity：具有唯一標示的實體，是持久化的基礎。

SessionBean和MDBean統(tǒng)稱為Enterprise Bean，這點不同于EJB2規(guī)范。EntityBean已經(jīng)劃分由持久化Provider去管理和控制，不再由EJB容器管理。

EJB3框架

它提供了對EJB3組件的各種支持，包括容器事務、安全服務、資源池的管理（包括線程池、連接池、實例池）以及組件生命周期的管理、并發(fā)支持等。

EJB3的核心features

1.       聲明式的元數(shù)據(jù)：通過Java5的Annotation或XML來聲明式地去指定Enterprise Bean和Entity Bean的行為和特性。如果同時使用兩種方式時，XML描述具有更高的優(yōu)先級。

2.       按異常配置：對于大量可使用default配置的地方都可以省去繁瑣的配置，只有需要不按默認行為的才需要顯式得通過注解或XML來進行描述。強調(diào)用戶只有需要配置時才進行配置，可以使代碼更為簡潔。

3.       良好的可伸縮性：EJB3的實現(xiàn)中在三個方面保證了良好的伸縮性，（1）通過資源池最大程度上對重新對象的重用；（2）使用持久化及緩存避免重復查詢和重復創(chuàng)建實體；（3）優(yōu)化的鎖定策略，避免對DB的并發(fā)鎖定。

4.       JTA（Java Transaction API）定義了分布式事務的標準API。EJB容器作為JTA的事務管理器。

5.       通過聲明的方式來控制方法級別的訪問控制，達到多層安全性。

6.       實體Bean被替換成POJO，簡單、輕量，不用再去實現(xiàn)專門的接口，同時可以脫離EJB容器。

7.       SessionBean也更加靈活，不再需要主接口（Home Interface）.

8.       依賴注入（dependency injection），可以通過Annotation或XML的方式將依賴數(shù)據(jù)“推（push）”到bean。例如：將EntityManager注入到SessionBean中，以使會話可以與持久化單元進行交互。

9.       攔截器和回調(diào)（Call-back）：通過攔截器來完成某些回調(diào)方法。

10.   對于SessionBean和MDB，不在需要主方法（ejbCreate()），使用默認構造器來替代。同時也不需要再擴展專有接口。

11.   對于EntityBean，主接口（Home interface）也被替換成EntityManager，后者是一個單例實例工廠，可以管理實體Bean的生命周期。

12.   EJB3的分布式計算模型：EJB3也基于RMI遠程服務，遠程接口方法按值傳遞以提供粗粒度的模型。

EJB3角色

1.       定義Enterprise Bean及相關meta-data的三種角色：

（1）       企業(yè)Bean提供者（Enterprise Bean provider），負責去定義和實現(xiàn)業(yè)務邏輯和結構；負責定義實體的持久化結構及互相關系。

（2）       應用裝配者（Application assembler）。

EJB3的會話Bean

EJB3中，SessionBean包括兩種類型，Stateful SessionBean和Stateless SessionBean。

顧名思義，Stateless SessionBean不需維持客戶請求的會話狀態(tài)；而Stateful SessionBean則需要維持特定客戶請求的會話狀態(tài)，同時bean實例也是用客戶請求綁定的。

Stateless SessionBean

無狀態(tài)會話Bean由兩個元素組成：業(yè)務接口，用來定義所提供的服務；bean類，是對服務接口的實現(xiàn)。注意此處，不需像EJB2.x中分別實現(xiàn)EJBObject和SessionBean接口。

通過示例，通過定義本地接口和（或）遠程接口來定義業(yè)務接口，這里Local接口和Remote接口的選擇遵循一個原則：如果業(yè)務的請求者與SessionBean處在同一個JVM中，則可以使用本地接口，反之則必須使用遠程接口。

原則上，如果同時使用了本地接口和遠程接口，則必須保證二者定義的接口一致，同時由實現(xiàn)的Bean實現(xiàn)這些方法。

無狀態(tài)會話Bean無需實現(xiàn)EJB特定的接口或擴展類，只需在類級別使用注解——@Stateless即可。同時也在本地接口及遠程接口的類級別添加注解——@Local和@Remote。

通過前面對EJB3特性的介紹，可以知道EJB3對DI（Dependency Injection）的良好支持！在EJB3中，可以將各類資源注入到會話Bean中，這些資源可以是其他的會話Bean、數(shù)據(jù)源或者是JMS中的隊列（Queue）等。要實現(xiàn)依賴注入可以通過添加注解，也可以在XML配置文件中進行描述，但需注意的是，如果二者都進行的配置則以XML文件中的描述為準。

以注解的方式為例，只需添加@Resource注解即可，注入可以通過兩種方式：實例變量和setter方法上。

回調(diào)（Call-back），通過回調(diào)，可以對Bean在其生命周期內(nèi)各個階段進行更細粒度的控制和管理。使用回調(diào)方法也很簡單，回調(diào)方法沒有多余的限制，只需添加正確的注解即可。

無狀態(tài)會話Bean兩個主要的用于回調(diào)方法的注解分別是：@PostConstruct和@PreDestroy。其中@PostConstruct的方法會在該bean被實例化后回調(diào)執(zhí)行，但需要注意的是，如果該bean有配置了需要注入的資源，那該回調(diào)方法則會緊跟著資源的注入之后而執(zhí)行。

@PreDestroy的回調(diào)方法則是在容器即將銷毀bean實例之前被調(diào)用，主要用來做一些善后的工作，比如對資源的關閉和清理。（補充，在有狀態(tài)會話Bean中，該方法是在最后一個帶有@Remove注解的方法調(diào)用后才被調(diào)用，之后容器銷毀bean實例。）

另一個關鍵的元素是攔截器（Interceptor），攔截器的使用也很便捷，通過添加正確的注解即可。攔截器的概念與其他JavaEE的框架或規(guī)范中的一致，即攔截業(yè)務方法的調(diào)用，可以在攔截點附加新的業(yè)務邏輯，結合依賴注入特性，可以充分得做到關注點分離（Separation of Concerns）。Enterprise Bean中會話Bean和消息驅(qū)動Bean可以定義攔截器方法。

攔截器注解可以添加到方法級別，也可以添加到類級別。被標注的方法在被調(diào)用時會被攔截器類攔截，并插隊式的先去調(diào)用攔截器的方法。對于用到的攔截器類需要添加@Interceptor注解，如果有多個攔截器則使用@Interceptors。

以@AroundInvoke注解為例，攔截器方法需要關注InvocationContext接口，通過它可以獲得被攔截的bean類（Class）、bean中的方法（Method）等，需要強調(diào)的是其中的proceed()方法，通過它將攔截請求往后傳遞，或者到攔截器鏈中的下一個，或者是結束攔截調(diào)用真正的bean方法。

EJB3規(guī)范中定義了兩種類型的異常，分別是應用異常和系統(tǒng)異常。應用異常是業(yè)務邏輯中產(chǎn)生的checked exception；而系統(tǒng)異常則是EJB系統(tǒng)級產(chǎn)生的異常，同時系統(tǒng)異常都是RemoteException和RuntimeException的子類，是unchecked exception。

有狀態(tài)會話Bean（Stateful SessionBean）在特性及細節(jié)上與無狀態(tài)會話Bean很相似。

會話Bean的用戶視圖

訪問會話Bean的用戶視圖可以有三種形式：

1.       通過Remote接口，遠程客戶具有位置無關性。

2.       通過Local接口，這兩種方式中請求方可以是其他的EJB組件，可以是Servlet、JSP等。需要注意的是，本地客戶具有位置依賴性。

3.       WebService方式，可以將會話Bean發(fā)布成為一個WebService，供客戶調(diào)用。

客戶請求會話Bean時，或者通過依賴注入或者通過查找JNDI，來獲得會話Bean的stub對象，請求是通過stub來進行調(diào)用的。對于無狀態(tài)會話Bean，每次請求將獲得新的stub，而有狀態(tài)會話Bean，則在請求方緩存stub，這樣才能使容器知道該返回哪個與客戶相關聯(lián)的bean實例。

通過依賴注入獲得會話Bean業(yè)務接口的方式是添加注解@EJB，注意要與@Resource區(qū)分開。

相比查找JNDI，使用注入的方式會更加簡潔，通常對于遠程請求使用JNDI更適合。

有狀態(tài)會話Bean（Stateful SessionBean）

通過實現(xiàn)SessionSynchronization接口，可以在事務點上獲得EJB容器的通知：afterBegin，在新事物開始時；beforeCompletion，在事物提交前；afterCompletion，在事物執(zhí)行完之后。

有狀態(tài)會話Bean中的回調(diào)方法除了PostConstruct和PreDestroy外，還有PreActivate和PrePassivate，分別使用@PreActivate和@PrePassivate來注解。

前兩個回調(diào)方法的細節(jié)與無狀態(tài)會話Bean一致，分別在（1）實例化Bean之后并執(zhí)行完資源注入后執(zhí)行；（2）@Remove方法執(zhí)行完畢之后。

對于有狀態(tài)會話Bean中的@Remove方法，也是一個管理bean生命周期的方法，調(diào)用該方法后，容器將會從實例池中將該bean刪除。

帶有@PrePassivate注解的方法會由EJB容器調(diào)用，當某個有狀態(tài)會話Bean實例長時間空閑，則容器調(diào)用該方法將此bean實例鈍化，并將狀態(tài)緩存起來。

當客戶請求再次需要使用被鈍化的某bean實例時，容器調(diào)用該bean的@PreActivate方法，返回一個創(chuàng)建好的并帶有狀態(tài)的新實例。

有狀態(tài)會話Bean的攔截器方法需要注意的是，如果實現(xiàn)SessionSynchronization接口的bean，afterBegin始終發(fā)生在@AroundInvoke的任何方法前。