【正文】 正文 (即負載 )。消息頭包含路由信息，也可能包含與消息過濾相關(guān)的信息，以及其他的一些屬性。這些屬性中可能包含 JMSPeplyTo。消息的發(fā)送者可以將 JMSReplyTo屬性設(shè)置為任何 JMS provider可以訪問到的消息目標地址。 消息選擇器 (Message selector) ? MDB可以聲明一個消息選擇器。消息選擇器允許 MDB選擇性地接收來自特定主題或隊列的消息。消息選擇器使用消息屬性(Message properties)作為條件表達式。這些條件表達式使用布爾邏輯來聲明哪些消息應(yīng)該被發(fā)送。在 @ActivationConfigProperty中，我們使用標準屬性 messageSelector來聲明消息選擇器。 @ActivationConfigProperty( propertyName=messageSelector, propertyValue=MessageFormat=39。Version 39。), 確認模式 ? JMS確認 (JMS acknowledgment)是指 JMS客戶端通知 JMS provider(消息路由 )確認消息已經(jīng)到達的一種機制。在 EJB中，確認模式有兩個取值： ? Autoacknowledge告訴容器，在消息交給 MDB實例處理后，容器應(yīng)該立即向 JMS provider發(fā)送一個確認。 ? Dupsokacknowledge則表示，容器不必立即向JMS provider發(fā)送確認，容器在 MDB實例收到消息后的任何時刻發(fā)送確認都是可按受的。使用Dupsokacknowledge模式時， MDB容器可能延遲很長時間才會發(fā)送確認，于是 JMS provider可能會認為容器沒有收到消息而發(fā)送了一條“重復(fù)的”消息。顯然，在使用 Dupsokacknowledge模式時，你的 MDB必須能夠正確處理重復(fù)消息。 訂閱的持續(xù)性 ? 當(dāng)基于 JMS的 MDB使用 ，我們必須在部署描述文件中聲明：這一訂閱是 Durable或NonDurable。 ? 聲明為 Durable的訂閱，其持續(xù)時間可以比 MDB容器指向 JMS provider的連接更長。因此，如果 EJB容器由于某些原因失去了與 JMS provider的連接，在此期間bean本應(yīng)收到的消息是不會丟失的。 JMS provider會保存這些消息，當(dāng)容器重新獲得連接之后，這些消息會經(jīng)由容器發(fā)送給 MDB。這種行為通常被稱作保存 轉(zhuǎn)發(fā)消息傳遞機制 (storeandforward messaging)。聲明為 Durable的 MDB可以容忍連接的丟失。 ? 如果訂閱被聲明為 NonDurable，那么 bean就會丟失連接斷開期間本應(yīng)收到的所有消息。如果不是嚴格要求所有消息都要被處理，開發(fā)人員可以使用 NonDurable訂閱模式。使用 NonDurable訂閱模式可以改善 JMS provider的性能，但是會嚴重降低 MDB的可靠性。 Messagedriven bean的生命周期 ? 和 session bean一樣， MDB也有定義完備的生命周期。 MDB實例的生命周期有兩個狀態(tài)： Does Not Exist和MethodReady Pool。 MethodReady Pool和 stateless session bean的對應(yīng)狀態(tài)相似，也使用了實例池。 MethodReady Pool狀態(tài) ? 當(dāng)容器需要某個 MDB時， MDB實例就進入了 MethodReady Pool狀態(tài)。當(dāng) EJB服務(wù)器首次啟動時，它可能會創(chuàng)造一些 MDB的實例，并使它們進入 MethodReady Pool狀態(tài) (服務(wù)器的實際行為取決于具體實現(xiàn) )。當(dāng) MDB實例的數(shù)量不足以處理發(fā)來的消息時，服務(wù)器就會創(chuàng)建更多的實例，并將它們添加到實例池中。 ? 你必須提供一個默認的構(gòu)造函數(shù)。默認構(gòu)造函數(shù)是一個不帶任何參數(shù)的構(gòu)造函數(shù)。這是由于，容器使用 ()初始化 bean class的實例時，是需要無參構(gòu)造函數(shù)的。如果 bean沒有定義任何構(gòu)造函數(shù)，則默認具有一個無參構(gòu)造函數(shù)。 MDB狀態(tài) ? 當(dāng)有消息送遞 MDB時，容器會將這條消息委派給任何一個處于 MethodReady Pool狀態(tài)的 bean實例。如果 bean實例正在處理某條消息，它就不能處理其他消息。 MDB可以同時處理多條消息，只要將每條消息委派給不同的 bean實例加以處理即可。 Bean實例在處理消息的時候，其 MessageDrivenContext會被更新，以反映新的事務(wù)上下文。一旦 bean實例結(jié)束了對消息的處理，它就可以馬上處理新的消息。 ? 當(dāng) EJB服務(wù)器不再需要 bean實例時 —— 例如，服務(wù)器決定移除一部分內(nèi)存對象以減少處于 MethodReady Pool狀態(tài)的 bean總數(shù)時 —— 它就會離開 MethodReady Pool狀態(tài)到達 Does Not Exist狀態(tài)。 Timer Service ? 業(yè)務(wù)系統(tǒng)常常會使用調(diào)度系統(tǒng) (scheduling system)來定時執(zhí)行程序。例如典型的，調(diào)度系統(tǒng)常常在夜間執(zhí)行一些應(yīng)用程序，如：生成報表，重新格式化數(shù)據(jù)，或完成審計工作。除此以外，調(diào)度系統(tǒng)還可能提供回調(diào)API，并以此來提醒子系統(tǒng)某些特殊事件。 ? 調(diào)度系統(tǒng)通常會執(zhí)行一些批處理作業(yè) (batch Job)，也稱為調(diào)度作業(yè) (scheduled Job)，在預(yù)定時間內(nèi)自動執(zhí)行例行的工作。 Timer Service ? 定時服務(wù)使 enterprise bean能夠在指定日期到達，經(jīng)歷一段時間，或者重復(fù)時間間隔到期之后，接收到相應(yīng)的通知。為了使用定時服務(wù)， enterprise bean必須實現(xiàn) ，該接口定義了一個回調(diào)方法， ejbTimeout()。 package javax． ejb； public interface TimedObject( public void ejbTimeout(Timer timer)； ) @Stateless public class ShipMaintenanceBean implements ShipMaintenanceRemote implements { public void ejbTimeout(Javax． ejb． Timer timer){ ／／此處為定時器的業(yè)務(wù)邏輯 } } Timer Service @Stateless public class ShipMaintenanceBean implement ShipMaintenanceRemote{ @Timeout public void maintenance( timer){ ／／此處為定時器的業(yè)務(wù)邏輯 } } TimeService接口 ? TimeService接口為 enterprise bean訪問 EJB容器的定時服務(wù)提供了支持，利用它可以創(chuàng)建新的定時器，列出已有定時器。 TimerService接口是 ，其定義如下。 public interface TimerService { // Create a singleaction timer that expires on a specified date. public Timer createTimer(Date expiration, Serializable info) throws IllegalArgumentException,IllegalStateException,EJBException。 // Create a singleaction timer that expires after a specified duration. public Timer createTimer(long duration, Serializable info) throws IllegalArgumentException,IllegalStateException,EJBException。 // Create an interval timer that starts on a specified date. public Timer createTimer( Date initialExpiration, long intervalDuration, Serializable info) throws IllegalArgumentException,IllegalStateException,EJBException。 // Create an interval timer that starts after a specified duration. public Timer createTimer( long initialDuration, long intervalDuration, Serializable info) throws IllegalArgumentException,IllegalStateException,EJBException。 // Get all the active timers associated with this bean public getTimers( ) throws IllegalStateException,EJBException。 } 定時器 ? Time對象實現(xiàn)了 。它代表了一個為使用定時服務(wù)的 enterprise bean而設(shè)置的定時事件。 public interface Timer( //取消定時器 public void cancel() //獲取與定時器相關(guān)的信息 public getInfo() //獲取下一次定時器到期的時間 public Date getNextTimeout() //獲取定時器下次到期之前所剩的時間 public long getTimeRemaining() //獲取一個可序列化的定時器句柄 public TimerHandle getHandle() } () ? ()方法。該方法的用途是從定時服務(wù)中取消一個特定的定時器，使之永遠無法到期。當(dāng)定時器需要被移除或重新調(diào)度時，我們就需要使用這一方法。為了重新安排定時事件，我們可以取消現(xiàn)有的定時器，并重新創(chuàng)建一個新的定時器。 ? 例如，當(dāng)某艘船只上的零部件發(fā)生了故障，并且已經(jīng)被更換，則對該零部件的維修任務(wù)就必須重新安排：如果 5月份已經(jīng)更換過引擎，那么在 6月進行全年定期的全面檢查就是不合理的。我們可以修改scheduleMaintenance()方法，為其增加一項新的維修任務(wù)，或替換已有的維修任務(wù)(取消已有的定時器，并添加一個新的 )。 標識定時器 ? 當(dāng)然，由于定時器的描述往往會隨時間發(fā)生變化，因此比較定時器的描述是一種相當(dāng)不可靠的定時器標識方式。我們需要一種更為可靠的信息 (同時包含文字描述和精確的標識符 )對定時器進行識別。 ? 所有的 TimeService． createTimer()方法都聲明了一個 info對象，作為其最后一個參數(shù)。 info對象是由定時服務(wù)保存的應(yīng)用數(shù)據(jù)，當(dāng)容器調(diào)用 enterprise bean的 timeout回調(diào)方法時，該 info對象就會被傳入回調(diào)方法 (注 1)。 info對象可以是實現(xiàn)了java． io． Serializable接口并遵循序列化語義的任何Java對象。它可以應(yīng)用于很多場合，不過最明顯的用途還是將其作為定時器的某種標識符。 事務(wù)四大特性： ACID ? 原子性 ? 一致性 ? 隔離性 ? 持久性 事務(wù)傳播屬性 ? NotSupported ? Supports ? Required ? RequiresNew ? Mandatory ? Never 事務(wù)并發(fā)問題 ? 第一類丟失更新 ? 臟讀 ? 不可重復(fù)讀 ? 第二類丟失更新 ? 幻影讀 數(shù)據(jù)庫鎖 ? 讀鎖 ? 避免不可重復(fù)讀 ? 寫鎖 ? 允許臟讀，避免第一類丟失更新 ? 排他寫鎖 ? 不允許臟讀 ? 快照 ? 避免臟讀，不可重復(fù)讀，幻影讀，但是數(shù)據(jù)不實時 事務(wù)隔離級別 ? Read unmitted ? Read mitted ? Repeatable read ? Serializable 如何控制并發(fā) ? 樂觀鎖 ? 悲觀鎖（ Hibernate） 安全是什么？ ? 驗證 ? 授權(quán) ? 機密性和完整性 安全處理 ? 驗證與身份 (, userName)。 (S, userPassword)。 InitialContext ctx = new InitialContext(properties)。 Object ref = (TravelAgent)。 TravelAgentRemote remote = (Travel