原创 JavaEE中的事務管理——bean託管的事務

bean託管的事務

原创 企業級開發的思考

以前自己一直認爲企業級開發是神聖的,是不容質疑的。儘管有時候自己也認可“多大屁股穿多大褲衩”的道理,但是那種重量級的開發模式在自己心目中佔據的位置一直是不容侵犯的。直到最近公司打算要做個東西的時候才發現企業級真的很重,重到90%以上的情況

原创 單例會話bean(1)

在EJB3.1之前在會話bean的種類中是沒有單例會話bean的,有的只是有狀態會話bean以及無狀態會話bean。毋庸置疑無狀態會話bean以其優秀的性能被普遍使用,但是人們發現在無狀態會話bean在使用過程中有兩個最常值得關注的問題。

原创 什麼時候使用有狀態會話bean

首先你應該清楚Session bean在服務器上是怎麼樣被創建以及管理的。拿無狀態會話bean來說服務器在實例池中維護了它的很多實例。每次客戶端請求的時候任意一個無狀態的會話bean都可能會被選擇出來,來對這個請求作出相應的處理。也就是說

原创 JavaEE中的依賴性——依賴查找

關於依賴性管理我們要介紹的第一個策略就是依賴查找(dependency lookup)。這種策略是JavaEE中傳統形式的依賴性管理,這裏可以看到JavaEE規範中的JNDI(Java Naming andDirectoryInterfa

原创 JavaEE中的依賴性管理

無論你多麼偉大你都不可能獨立完成一項偉大的任務,JavaEE組件也是一樣的,沒有那個組件可以獨立完成所有的任務。一個組件在工作的時候往往需要其他資源的幫助,那麼在尋求幫助的過程中就涉及到這次我們要說的“依賴性管理”的問題。比如一個簡單的會

原创 雲計算的由來——技術積累

IT領域和娛樂圈一樣每個階段總有那麼幾個技術(娛樂人物)去搶頭條。今天就來聊一聊雲計算,就像去評價一個娛樂人物一樣,誰也說不清這個人到底是什麼樣子。因爲在一定的時間裏麪人們對一個東西的認識往往是片面的。你不可能說就憑一篇出軌報道就說哪個明

原创 雲計算在企業中的應用(2)

雲計算之所以能在企業當中運轉這歸功於Dynamic infrastructure(動態基礎設施),有了這個做基礎纔有了上層Platform的發展空間。傳統的JavaEE在解決企業當中大量計算的時候是通過集羣實現的,當遇到瓶頸就增加節點。但

原创 JavaEE中的依賴性——依賴性注入

當一個資源註解防止在一個字段或setter方法之上時,將會發生兩件事。首先,就像放置在bean類之上一樣聲明資源引用(類似於上文中的代碼示例),而且當創建組件時將把資源名稱綁定到環境命名上下文。第二,該服務器將爲您自動進行依賴性查找,並把

原创 JavaEE中的事務管理——事務概述

今天打算說一說事務管理,讀者可能瞭解也有可能不瞭解,其實很簡單(大牛請自行繞過)。本來想引用個成語的啥的來描述事務的特點,但是搜腸刮肚也沒有發現合適的,於是就找了下面幾組成語來描述事務性。其實在官方文檔中對於事務的描述也是分四個方面來說的

原创 放下

前幾天在補測試用例的時候,想學習一下如何使用mock進行單元測試,於是找到了Junit in action的書。先是大概的瀏覽了一遍目錄然後我陷入了思考,是應該從頭到尾的看完還是找自己不會的地方重點看?很明顯前一種方法可以讓我瞭解Juni

原创 單例會話bean(2)----生命週期回調與併發性

生命週期回調在生命週期回調方面單例會話bean與無狀態會話bean在大體上是一樣的,都擁有下面兩個回調PostConstruct和PreDestroy。這連個回調分別是容器在服務器初始化bean實例之後以及釋放bean實例之前調用。對於單

原创 有狀態會話bean

在會話bean綜述中,描述了無狀態和有狀態bean的區別在於客戶端和服務器之間交互形式不同。對於無狀態會話bean,交互的開始和結束都在同一個方法中。有時客戶端需要發出多個服務請求(需要調用多個方法),而每個請求需要訪問或者考慮前面的請求

原创 JPA對象關係映射——訪問實體狀態

訪問實體狀態

原创 人類一思考,上帝就發笑(慌)

最近看了一本書叫做《時間的形狀》,一本講相對論的書,很有意思,值得一讀。讀完了之後感覺茫茫宇宙你我只不過是其中的一粒塵埃,生活中的不順,工作中的壓力相對於宇宙來說太渺小了。你的行爲,別人的行爲,發生的事情歸根結底都是宇宙的一部分,都是“註