/* Author: J@mes */

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

 

EJB3的事務與安全

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

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

 

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

 

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

 

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

 

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

 

事務管理

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

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

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

 

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

 

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

 

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

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

TransactionAttributeType有幾個枚舉值：

（1）      REQUIRED：如果調用者沒有事務，容器則創建新事務；如果調用者具有事務，容器則連接join調用者事務。

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

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

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

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

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

 

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

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

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

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

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

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

 

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

CMT事務管理的真正機制

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

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

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

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

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

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

@AplicationException注解

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

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

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

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

 

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

 

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

EJB3學習總結（1）

現狀

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

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

EJB3規范

EJB3規范包含3個技術文檔：

1.       EJB3 Simplified API

2.       EJB3 Core Contracts & Requirement

3.       Java Persistence API

EJB3組件模型

1.       Session Bean：執行業務服務、控制事務及資源訪問

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

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

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

EJB3框架

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

EJB3的核心features

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

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

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

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

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

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

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

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

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

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

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

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

EJB3角色

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

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

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

EJB3的會話Bean

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

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

Stateless SessionBean

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

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

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

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

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

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

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

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

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

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

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

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

EJB3規范中定義了兩種類型的異常，分別是應用異常和系統異常。應用異常是業務邏輯中產生的checked exception；而系統異常則是EJB系統級產生的異常，同時系統異常都是RemoteException和RuntimeException的子類，是unchecked exception。

有狀態會話Bean（Stateful SessionBean）在特性及細節上與無狀態會話Bean很相似。

會話Bean的用戶視圖

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

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

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

3.       WebService方式，可以將會話Bean發布成為一個WebService，供客戶調用。

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

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

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

有狀態會話Bean（Stateful SessionBean）

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

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

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

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

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

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

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