生活随笔
收集整理的這篇文章主要介紹了
欢迎参与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ù)庫設置為最高隔離級別
> 庋拍鼙Ｖづ縰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)容還不錯，歡迎將生活随笔推薦給好友。
