事務規(guī)范包括？排查各個系統(tǒng)的代碼，檢查在事務中是否存在RPC全局函數(shù)、HTTP動態(tài)鏈接庫、消息隊列操作、緩存、循環(huán)查詢等工程巨大的操作，這個操作肯定移到事務之外，美好的理想的情況是事務內(nèi)只一次性處理數(shù)

事務規(guī)范包括？

排查各個系統(tǒng)的代碼，檢查在事務中是否存在RPC全局函數(shù)、HTTP動態(tài)鏈接庫、消息隊列操作、緩存、循環(huán)查詢等工程巨大的操作，這個操作肯定移到事務之外，美好的理想的情況是事務內(nèi)只一次性處理數(shù)據(jù)庫操作。

對大事務直接添加監(jiān)控報警。大事務再一次發(fā)生時，會發(fā)來郵件和短信提醒。針對數(shù)據(jù)庫事務，像是統(tǒng)稱1s以上、500ms以上、100ms以上三種級別的事務報警。

見意最好別用XML配置事務，而常規(guī)注解的。原因是XML配置事務，第一可讀性不強，第二切面大多配置的都很泛濫，很容易倒致事務過大，第三對于嵌套情況的規(guī)則當然不好如何處理。

兩個不同數(shù)據(jù)庫，同一事務，怎么控制？

你兩個數(shù)據(jù)庫是一個連接嗎是兩個連接的話,就未每個再連接各開一個事務不就可以了嗎當然了那個先那個后的哦,在第二個執(zhí)行完了先commit最后一個再commit第二個出現(xiàn)在commit時程序出錯的很可能有多少就像數(shù)據(jù)錯誤在再提交時的錯誤比較少吧

數(shù)據(jù)庫的創(chuàng)建是通過什么完成的？

數(shù)據(jù)庫是依據(jù)什么“數(shù)據(jù)模型”組建的。數(shù)據(jù)模型是對再現(xiàn)實世界數(shù)據(jù)特征的仿真的和抽象，它從抽象的概念層次上請看了系統(tǒng)的動態(tài)和靜態(tài)特征、動態(tài)行為和約束條件，為數(shù)據(jù)庫系統(tǒng)的信息可以表示與操作提供一個抽象的框架。

模型可更形象、形象直觀地論述事物的本質(zhì)特征，使人們對事物有一個更加全面、踏入的認識，從而可以不解決人們更合適地能夠解決問題。依靠模型對事物進行詳細解釋是人們在認識和新的改造世界過程中應用廣泛需要的一種方法。計算機又不能真接一次性處理不是現(xiàn)實世界中的客觀的評價事物，而數(shù)據(jù)庫系統(tǒng)恰好可以使用計算機技術對客觀意義事物接受管理，并且就要對客觀事物并且抽象概念、仿真的，以確立適合我于數(shù)據(jù)庫系統(tǒng)接受管理的數(shù)據(jù)模型。數(shù)據(jù)模型是對再現(xiàn)實世界數(shù)據(jù)特征的設計模擬和抽象。

事務是由什么來管理的？

事務應該是對一系列的數(shù)據(jù)庫操作（比如插到多條數(shù)據(jù)）通過統(tǒng)一的遞交或回滾操作，如果不是插到順利，那就在一起完成，如果不是中間有一條又出現(xiàn)異樣，這樣的話回滾之前的所有操作。這樣的話這個可以防止直接出現(xiàn)臟數(shù)據(jù)，避兔數(shù)據(jù)庫數(shù)據(jù)又出現(xiàn)問題。

開發(fā)中是為盡量避免那種情況像是都會并且事務管理。

在JDBC中是是從Connection對象并且事務管理的，默認是不自動并提交事務，可以手工將手動重新提交關了，通過commit方法參與再提交，rollback方法通過回滾，如果不遞交，則數(shù)據(jù)不可能真正的插到到數(shù)據(jù)庫中。

Hibernate中是是從Transaction進行事務管理，處理方法與JDBC中相似。

Spring中也有自己的事務管理機制，一般是在用TransactionMananger并且管理，這個可以通過Spring的注入來完成此功能。