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