生活随笔
收集整理的這篇文章主要介紹了
欢迎参与Java 事务讨论
小編覺得挺不錯的,現(xiàn)在分享給大家,幫大家做個參考.
歡迎參與Java 事務討論 bruce http://www.jdon.com Jul 14, 2003 6:13 AM 回復 ***************************** **JTA與JDBC中事務處理的區(qū)別** ***************************** JTA(Java Transaction API) , 如begin(), commit() JDBC中也有事務處理的API, 如begin(), commit()
兩者都是控制事務的API, 不知它們有什么區(qū)別? 是不是底層實現(xiàn)相同?
**************************************** **另外,也談談我對CMP與Hibernate的理解** **************************************** 顯然,CMP在處理復雜的查詢時弱于Hibernate. CMP也沒有動態(tài)查詢。 但是,CMP在事務處理方面強于Hibernate, 原因是CMP與EJB容器結合,其CMT直接在Declarative transaction申明事務的類型,其它的事情交給EJB容器,代碼量少,也容易維護。
********************************************************* **在EJB中用hibernate代替CMP的可行性到底有多少?(好與壞)** *********************************************************
|
| | Re: 歡迎參與Java 事務討論 | 發(fā)表時間: Jul 14, 2003 9:00 PM | | | 發(fā)表人: bruce ?? 發(fā)表文章: 190 / 注冊時間: 2003-05 | | 頂一頂. 不相信大家對此不感興趣。 |
|
| | Re: 歡迎參與Java 事務討論 | 發(fā)表時間: Jul 14, 2003 9:54 PM | | | 發(fā)表人: blues ?? 發(fā)表文章: 60 / 注冊時間: 2002-09 | 先說一說hibernate: 在此之前大家對hibernate進行了很多討論。由于我沒有真正在項目中使用過hibernate,所以不敢亂說。但看了一些資料和使用hibernate的Sample后,我感覺使用hibernate并非會有根本性的好處(當然cmp也不是必須使用的)。 先列出2種后臺層次結構: 1.一個使用hibernate的sample sessionBean --> (domain object) -->DAO -->hibernate 2.我在上一個項目中使用的結構 sessionBean --> (domain object) -->DAO 比較上面2種結構,區(qū)別在于: 方式1在DAO中使用了hibernate進行persistence工作,實現(xiàn)對關系型數(shù)據(jù)庫的操作;而我方式2中,是在DAO中使用jdbc直接操作關系數(shù)據(jù)庫。
我的結論是: 1.方式1能做的事情,在方式2中都能做;而方式2能做的事情方式1不一定能勝任。例如在DAO優(yōu)化方面,方式2要比方式1更靈活;
2.方式1在代碼量方面不比方式2少。--實際上方式1需要維護的是o/r mapping 文件,而方式2可以通過代碼生成工具方便地生成絕大部分代碼
3.o/r mapping的概念,更應該是一個面向?qū)ο笤O計的原則。在實現(xiàn)的時候,直接在DAO使用JDBC操作數(shù)據(jù)庫也是一種o/r 轉(zhuǎn)換的做法。因此還是沒有理由一定要使用hibernate。
說的片面之處,請各位指正. |
|
| | Re: 歡迎參與Java 事務討論 | 發(fā)表時間: Jul 15, 2003 3:05 AM | | | 發(fā)表人: bruce ?? 發(fā)表文章: 190 / 注冊時間: 2003-05 | Hibernate好處很多,這也是為什么大家對此如此關注的原因。
sessionBean --> DAO(JDBC+SQL) 業(yè)務邏輯與數(shù)據(jù)庫偶合太密。不利于擴展及維護。這個我以前做項目深有體會,特別是SQL量大的時候。并且ORM在數(shù)據(jù)庫端是透明的,以前做項目用一種數(shù)據(jù)庫SQL Server,后來又讓支持另一種數(shù)據(jù)庫Oracle,光寫傳參數(shù)和寫if 語名判斷不說,連有些SQL語句也要變,現(xiàn)在想起來還記憶有新。
所以我們才會用ORM這種映射。
“1.方式1能做的事情,在方式2中都能做;而方式2能做的事情方式1不一定能勝任。例如在DAO優(yōu)化方面,方式2要比方式1更靈活; ” Hibernate在SQL優(yōu)化方面已經(jīng)幫我們做了很多,自已優(yōu)化需要對JDBC了解較深入,學習周期長。
“方式1在代碼量方面不比方式2少。--實際上方式1需要維護的是o/r mapping 文件,而方式2可以通過代碼生成工具方便地生成絕大部分代碼 ” ORM 文件可以通過XDoclet去做,很方便,即使是Ojbect的屬性有變化,只需用Xdoclet重新生成一次就行。但我現(xiàn)在還不知道如果數(shù)據(jù)庫端若有變化,如何將變化自動或半自動的反映到Object這邊,我對Hibernate還在了解中。
|
|
| | Re: 歡迎參與Java 事務討論 | 發(fā)表時間: Jul 15, 2003 12:46 PM | | | 發(fā)表人: guty ?? 發(fā)表文章: 55 / 注冊時間: 2003-06 | > sessionBean --> (domain object) -->DAO -->hibernate
為什么要這么麻煩,
hibernate API 直接 service ---------------> POJO 不就可以了?
|
|
| | Re: 歡迎參與Java 事務討論 | 發(fā)表時間: Jul 15, 2003 12:51 PM | | | 發(fā)表人: guty ?? 發(fā)表文章: 55 / 注冊時間: 2003-06 | | 用了O-R Mapping工具,DAO是不需要存在的 |
|
| | Re: 歡迎參與Java 事務討論 | 發(fā)表時間: Jul 15, 2003 10:21 PM | | | 發(fā)表人: bruce ?? 發(fā)表文章: 190 / 注冊時間: 2003-05 | | JDBC是一種DAO,ORM也是一種DAO。關鍵看DAO怎么定義了。 |
|
| | Re: 歡迎參與Java 事務討論 | 發(fā)表時間: Jul 15, 2003 10:30 PM | | | 發(fā)表人: blues ?? 發(fā)表文章: 60 / 注冊時間: 2002-09 | to guty: 我理解hibernate與jdbc是同一層次的東西。
"使用hibernate后就不需要DAO" I don't think so.用不用hibernate與用不用DAO沒有必然聯(lián)系。這其實涉及到對DAO的作用的理解。DAO的一個重要目的是為了將"操作"/"屬性"分開。 回頭再看你所提出的結構:session bean ->POJO 在這個結構中,POJO的功能是"操作"+"屬性"; 如果我們愿意讓"操作"+"屬性"不分開,自然也可以不用DAO,如下: session bean ->java object 其中java object是(數(shù)據(jù)庫操作+value object)。
但我們都不愿意這么做,而是將java object分割為DAO+value object
--請指教
to robbin: >澄清一個事實:Hibernate本身沒有事務處理功能!
I think so.使用container的transaction,在transaction context中調(diào)用hibernate就OK。當然hibernate中所使用的connection從txDatasource中獲取 |
|
| | Re: 歡迎參與Java 事務討論 | 發(fā)表時間: Jul 14, 2003 11:45 PM | | | 發(fā)表人: robbin ?? 發(fā)表文章: 584 / 注冊時間: 2003-06 | >>**JTA與JDBC中事務處理的區(qū)別**
去找本教科書看
>>CMP在事務處理方面強于Hibernate, 原因是CMP與EJB容器結合,其CMT直接在Declarative transaction申明事務的類型,其它的事情交給EJB容器,代碼量少,也容易維護
澄清一個事實:Hibernate本身沒有事務處理功能!
如果在Session Bean里面調(diào)用Hibernate,一樣可以使用CMT。(即利用JTA來管理事務!)
CMP的代碼量比Hibernate只多不少,可維護性更加是一場惡夢!不要憑空去想,實際做做項目你就知道了。
>>**在EJB中用hibernate代替CMP的可行性到底有多少?(好與壞)**
如果你覺得你可以用Session Bean + DAO + JDBC可以取代Session Bean + CMP,那么你就可以一樣用Session Bean + DAO + Hibernate取代 Session Bean + CMP。
Hibernate只不過是JDBC的一個非常好用,非常簡單的lightweight的對象封裝框架而已,沒有必要老是拿來和CMP做對比。凡是用JDBC的地方,你都可以用Hibernate,僅此而已。
|
|
| | Re: 歡迎參與Java 事務討論 | 發(fā)表時間: Jul 15, 2003 4:27 AM | | | 發(fā)表人: bruce ?? 發(fā)表文章: 190 / 注冊時間: 2003-05 | hi, robbin,以下我的總結不知是否正確,還望指點。
JDBC和JTA是BMT中的兩種事務類型。 JDBC 事務受數(shù)據(jù)庫的事務管理器控制。JTA 允許事務在不受數(shù)據(jù)庫的事務管理器控制的情況下劃分事務, EJB中利用JTS實施事務管理器,在代碼中調(diào)用JTA方法,由JTA調(diào)用JTS提供的服務。所以JTA受JTS控制,JTS支持JTA. 如果事務要跨不同的數(shù)據(jù)庫,就需要一個JTA事務。在BMT的SessionBean 中,也可以將 JDBC 和 JTA 事務混合在一起。但是這樣做容易引起混亂,不利于維護代碼。
我對hibernate還在了解中,可能看問題太片面。我想說的是,CMT比BMT代碼量少。如果hibernate也可以用在CMT中,那SessionBean+hibernate確實是一個不錯的組合。 |
|
| | Re: 歡迎參與Java 事務討論 | 發(fā)表時間: Jul 15, 2003 1:04 AM | | | 發(fā)表人: robbin ?? 發(fā)表文章: 584 / 注冊時間: 2003-06 | >>**在EJB中用hibernate代替CMP的可行性到底有多少?(好與壞)**
Hibernate的優(yōu)點有很多,我相信前面的帖子已經(jīng)討論的夠充分了。簡單,易用,強大,靈活而且速度夠快。
Hibernate的缺點從功能上來說,不適合處理批量update和delete(這也是ORM共同的缺點)。HQL只有select,沒有update和delete。本來在HQL里面增加update和delete只不過是舉手之勞而已。但是一旦在HQL里面增加update和delete,必須同步更新在JVM里面的persistent object,否則會造成persisent object的狀態(tài)不一致的問題。這邊廂數(shù)據(jù)庫里面的記錄已經(jīng)被刪除了,那邊廂persistent object還在JVM里面好好的運行呢!
所以Gavin King建議批量update和delete使用JDBC,這也符合他的軟件哲學,把95%的事情做到最好,剩下5%的瓶頸交給JDBC,“非不能也,是不為也”。
不過,實際上在一個面向用戶交互的軟件中,極少會遇到批量更新和批量刪除的情況,即便遇到,批量處理的記錄數(shù)也不會很多,一般用Hibernate處理也足夠了。只有一些數(shù)據(jù)庫后臺維護程序會比較頻繁的使用批量更新和批量刪除,但對于這樣的情況,直接使用數(shù)據(jù)庫的C API更加符合要求。 另一個我曾經(jīng)認為是Hibernate的缺點是不支持動態(tài)映射數(shù)據(jù)庫表,不支持映射非表的其他數(shù)據(jù)庫對象,當然這也是JDO,CMP同樣的面臨的問題。但我最近幾天發(fā)現(xiàn)Hibernate完全可以做到。
在Hibernate中,persistent object通過XML Mapping文件映射到數(shù)據(jù)庫表上,這樣就不能動態(tài)映射不同的表,比如有時候會遇到根據(jù)不同的情況選擇是從當前表還是從歷史表中進行查詢。不過persistent object通過XML Mapping文件也可以選擇不映射數(shù)據(jù)庫表,而是映射到一個Java class上,這樣就可以自己編寫一個ClassPersister,處理如何把persistent object和數(shù)據(jù)庫進行數(shù)據(jù)映射。更進一步,通過該方法,也可以解決在Hibernate中調(diào)用Store procedure的問題。
說實話,從功能上就ORM這一點來說,我還沒有發(fā)現(xiàn)Hibernate的缺點,大概是因為我對Hibernate研究還不夠深入吧。 |
|
| | Re: 歡迎參與Java 事務討論 | 發(fā)表時間: Jul 15, 2003 4:44 AM | | | 發(fā)表人: bruce ?? 發(fā)表文章: 190 / 注冊時間: 2003-05 | "但是一旦在HQL里面增加update和delete,必須同步更新在JVM里面的persistent object,否則會造成persisent object的狀態(tài)不一致的問題。這邊廂數(shù)據(jù)庫里面的記錄已經(jīng)被刪除了,那邊廂persistent object還在JVM里面好好的運行呢!"
的確,如果在同步的話,性能必定要打折扣。看樣Gavin King也很圓滑呀。
"在Hibernate中,persistent object通過XML Mapping文件映射到數(shù)據(jù)庫表上,這樣就不能動態(tài)映射不同的表,比如有時候會遇到根據(jù)不同的情況選擇是從當前表還是從歷史表中進行查詢。不過persistent object通過XML Mapping文件也可以選擇不映射數(shù)據(jù)庫表,而是映射到一個Java class上,這樣就可以自己編寫一個ClassPersister,處理如何把persistent object和數(shù)據(jù)庫進行數(shù)據(jù)映射。更進一步,通過該方法,也可以解決在Hibernate中調(diào)用Store procedure的問題。"
你的意思是不是這個被映射的Java class,做為一個control的功能,然后由它來指向不同的數(shù)據(jù)庫表。 如果是的話,那Hibernate功能實在強大。有沒有相關的URL? 我也想研究一下。 |
|
| | Re: 歡迎參與Java 事務討論 | 發(fā)表時間: Jul 15, 2003 9:11 AM | | | 發(fā)表人: robbin ?? 發(fā)表文章: 584 / 注冊時間: 2003-06 | >>sessionBean --> DAO(JDBC+SQL) 業(yè)務邏輯與數(shù)據(jù)庫偶合太密。不利于擴展及維護。
用ORM的原因主要不是因為降低耦合。使用JDBC并不會造成和數(shù)據(jù)庫過分的耦合,除非你總是用數(shù)據(jù)庫擴展的SQL,而不是ANSI SQL92。當然ORM和數(shù)據(jù)庫的耦合度更低。
自己使用JDBC來實現(xiàn)ORM絕不是blues說的那么容易的,要處理大量很棘手的問題,否則ORM就沒有存在的必要了。簡單的來說,一個復合持久對象你用JDBC實現(xiàn)ORM就非常麻煩,主要的困難不在于多表查詢,在于你怎么實現(xiàn)動態(tài)的lazy loading?我相信blues沒有用JDBC做過復雜的ORM工作,否則就不會這樣想當然了。我在沒有聽說過ORM之前就是自己手工寫JDBC代碼來實現(xiàn)ORM的,一旦持久對象之間存在復雜的組合和聚合關系,很難按照OO設計做下去了。我曾經(jīng)為此頭疼過很久,一直沒有好的解決辦法,直到接觸JDO和Hibernate,才算找到答案。
>>但我現(xiàn)在還不知道如果數(shù)據(jù)庫端若有變化,如何將變化自動或半自動的反映到Object這邊
http://hibernate.bluemars.net/52.html
ReverseEngTool可以這樣做,但還不夠好。可以手工修改XML Mapping File,然后用CodeGenerator自動生成代碼。
>>在BMT的SessionBean 中,也可以將 JDBC 和 JTA 事務混合在一起。但是這樣做容易引起混亂,不利于維護代碼
不能混合使用,事務不能嵌套,會報錯的。本質(zhì)上來說,JDBC事務是由數(shù)據(jù)庫管理的,JTA事務是由App Server容器的事務管理器來管理的。JTA可以實現(xiàn)跨數(shù)據(jù)庫連接,跨域的事務控制。
在多個數(shù)據(jù)庫參與事務的情況下,JTA管理方式頗有不同,需要啟動2PC。第一階段通知參與事務的各資源準備提交,如果有資源沒有準備好,全體放棄;第二階段真正提交,并且記錄日志。另外JTA除了可以管理數(shù)據(jù)庫資源外,也可以管理其他資源,比如JMS。
>>你的意思是不是這個被映射的Java class,做為一個control的功能,然后由它來指向不同的數(shù)據(jù)庫表。
對。Hibernate里面提供了一個接口ClassPersister,其抽象了persistent class和數(shù)據(jù)庫對象的映射操作。同時Hibernate也提供了兩個 ClassPersister接口的具體實現(xiàn)類:
EntityPersister:根據(jù)Mapping 文件中定義的對象屬性和表字段映射關系,處理"table-per-class-hierarchy" mapping NormalizedEntityPersister:根據(jù)Mapping 文件中定義的對象屬性和表字段映射關系,處理"table-per-subclass" mapping
默認情況下,Hibernate就是調(diào)用EntityPersister和NormalizedEntityPersister 來處理對象和表映射的。但如果EntityPersister和NormalizedEntityPersister都不能滿足你的要求的話,就可以自己寫一個ClassPersister的實現(xiàn)類,處理更復雜多變的動態(tài)映射關系。
最后在XML Mapping文件里面指定使用你自己寫的ClassPersister實現(xiàn)類,而不使用默認的EntityPersister。由此也可以看出Hibernate本身具有很強的可擴展性,如果Hibernate功能不能滿足你的需要,還可以自己擴充Hibernate的功能。相關介紹和例子見Hibernate文檔第4.1.3節(jié):
http://hibernate.bluemars.net/hib_docs/reference/html/or-mapping.html#or-mapping-s1-3
|
|
| | | Re: 歡迎參與Java 事務討論 | 發(fā)表時間: Jul 15, 2003 10:56 AM | | | 發(fā)表人: bruce ?? 發(fā)表文章: 190 / 注冊時間: 2003-05 | 多謝robbin的 Reference URL,我會仔細看看的。
ORM的優(yōu)勢我總結為: 將對象映像到關系數(shù)據(jù)庫,多分出一個持久層,減少耦合.對關系數(shù)據(jù)庫結構的簡單改動并不影響你的面向?qū)ο蟠a的。而且應用程序開發(fā)者不需要了解關系數(shù)據(jù)庫結構,事實上,他們甚至不需要知道對象是保存在關系數(shù)據(jù)庫中。
"我在沒有聽說過ORM之前就是自己手工寫JDBC代碼來實現(xiàn)ORM的,一旦持久對象之間存在復雜的組合和聚合關系,很難按照OO設計做下去了" 厲害,凡是自已寫ORM的人都不簡單。佩服! 的確,對象之間的關系太難處理。一對一,一對多,多對多還可以通過外鍵和association 表解決,但對于組合和聚合這種M-M,O-M 關系來說,考慮增刪改就太復雜了。這也就是老外說的 impedance mismatch. 關系數(shù)據(jù)庫是基于關系數(shù)學,無法充分體現(xiàn)OO的關系。
"不能混合使用,事務不能嵌套,會報錯的" 我可沒說這兩個要嵌套使用,難道JDBC和JTA不能是并行的關系,各管各的?
"在多個數(shù)據(jù)庫參與事務的情況下,JTA管理方式頗有不同,需要啟動2PC。第一階段通知參與事務的各資源準備提交,如果有資源沒有準備好,全體放棄;第二階段真正提交,并且記錄日志"
在第一階段還有一個叫交易日志,不知與第二階級參與者和協(xié)調(diào)者提交或中止記錄寫入的日志有什么區(qū)別?感覺是一樣的。
另外,感覺2PC容易形成瓶頸.
"除非你總是用數(shù)據(jù)庫擴展的SQL,而不是ANSI SQL92" 時間長了,我也記不得了,只記得那時SQL Server 與Oracle的左聯(lián),右聯(lián)SQL語句寫法不同,那時改得真的都發(fā)毛了。 |
|
| | Re: 歡迎參與Java 事務討論 | 發(fā)表時間: Jul 25, 2003 10:24 PM | | | 發(fā)表人: newjoy ?? 發(fā)表文章: 9 / 注冊時間: 2003-06 | | good |
|
| | Re: 歡迎參與Java 事務討論 | 發(fā)表時間: Jul 15, 2003 12:19 PM | | | 發(fā)表人: zzeric ?? 發(fā)表文章: 21 / 注冊時間: 2002-10 | | Robbin,如果使用JDBC來進行update/delete操作,會不會在Hibernate的cache里得到反映?如果可以,我很想知道Hibernate是怎么知道何時需要更新cache的 |
|
| | Re: 歡迎參與Java 事務討論 | 發(fā)表時間: Jul 15, 2003 1:26 PM | | | 發(fā)表人: robbin ?? 發(fā)表文章: 584 / 注冊時間: 2003-06 | > Robbin,如果使用JDBC來進行update/delete操作,會不會在H > bernate的cache里得到反映?如果可以,我很想知道Hibernat > 是怎么知道何時需要更新cache的
你的問題問得很好!答案是不可以。
上面我提到如果Hibernate可以在HQL里面批量update/delete,那么必須進行POJO的同步,這里面隱含一個前提,就是在同一個數(shù)據(jù)庫連接里面處理。如果不是在同一個數(shù)據(jù)庫連接里面處理的話,其實就不是Java程序能夠控制的了,需要根據(jù)數(shù)據(jù)庫設定的隔離級別來確定到底會產(chǎn)生什么樣的結果。
|
|
| | Re: 歡迎參與Java 事務討論 | 發(fā)表時間: Jul 15, 2003 10:19 PM | | | 發(fā)表人: bruce ?? 發(fā)表文章: 190 / 注冊時間: 2003-05 | "上面我提到如果Hibernate可以在HQL里面批量update/delete,那么必須進行POJO的同步,這里面隱含一個前提,就是在同一個數(shù)據(jù)庫連接里面處理。如果不是在同一個數(shù)據(jù)庫連接里面處理的話,其實就不是Java程序能夠控制的了,需要根據(jù)數(shù)據(jù)庫設定的隔離級別來確定到底會產(chǎn)生什么樣的結果。"
不知我的理解是否正確。 你的意思是不是,如果在同一個數(shù)據(jù)庫連接里面處理的話,通過設置JDBC transaction 隔離級別為Serializable mode? 如果是跨多個數(shù)據(jù)庫的話,所有的數(shù)據(jù)庫設置為最高隔離級別,這樣才能保證批量update/delete完整性和一致性.
|
|
| | Re: 歡迎參與Java 事務討論 | 發(fā)表時間: Jul 16, 2003 12:18 AM | | | 發(fā)表人: robbin ?? 發(fā)表文章: 584 / 注冊時間: 2003-06 | > 不知我的理解是否正確。 > 你的意思是不是,如果在同一個數(shù)據(jù)庫連接里面處理的話,通 > 柚肑DBC transaction 隔離級別為Serializable mode? > 如果是跨多個數(shù)據(jù)庫的話,所有的數(shù)據(jù)庫設置為最高隔離級別 > 庋拍鼙Vづ縰pdate/delete完整性和一致性. >
你誤解了。我的意思很簡單,如果在一個數(shù)據(jù)庫連接中,既用Hibernate修改數(shù)據(jù)庫,又用JDBC直接修改數(shù)據(jù)庫,當然要考慮POJO同步的問題。如果分別在不同的數(shù)據(jù)庫連接中各自干各的,本來互不干擾,就根本沒有必要去管數(shù)據(jù)同步問題。
|
|
| | Re: 歡迎參與Java 事務討論 | 發(fā)表時間: Jul 21, 2003 10:31 AM | | | 發(fā)表人: yyanghhong ?? 發(fā)表文章: 61 / 注冊時間: 2003-06 | | Hibernate有一個很方便的功能, 它把持久層對象中的表數(shù)據(jù)定義從代碼中分離出來, 防在配置文件中, 這比傳統(tǒng)ORM使用code generator的方法要自動高效. 在struts中action mapping也采用了類似的方法, 這些簡潔實用的設計在好的架構中應用的很普遍. |
|
轉(zhuǎn)載于:https://www.cnblogs.com/sunsonbaby/archive/2005/01/03/85975.html
總結
以上是生活随笔為你收集整理的欢迎参与Java 事务讨论的全部內(nèi)容,希望文章能夠幫你解決所遇到的問題。
如果覺得生活随笔網(wǎng)站內(nèi)容還不錯,歡迎將生活随笔推薦給好友。