❶ mysql中為什麼要使用xa事務
在XA事務中啟用InnoDB支持兩階段提交，導致額外的磁碟刷新事務准備。 XA機制在內部使用，對於其二進制日誌處於打開狀態且正在接受來自多個線程的數據更改的任何伺服器而言，都是必不可少的。如果您禁用了innodb_support_xa，那麼事務可以以不同於實時資料庫提交的順序的方式寫入二進制日誌，當二進制日誌在災難恢復或復制從屬環境中重播時，這可能會產生不同的數據。不要在復制主伺服器上禁用innodb_support_xa，除非有異常的設置，只有一個線程可以更改數據。
對於僅從一個線程接受數據更改的伺服器，這是安全的，建議禁用此選項以提高InnoDB表的性能。例如，您可以在只有復制SQL線程正在更改數據的復制從伺服器上將其關閉。
❷ 如何實現XA式，非XA式Spring分布式事務
Java Transaction
API和XA協議是Spring常用的分布式事務機制，不過你可以選擇選擇其他的實現方式。理想的實現取決於你的應用程序使用何種資源，你願意在性能、安
全、系統穩健性、數據完整方面做出何種權衡。在這次JavaWorld大會上，來自SpringSource的David
Syer跟大家分享了Spring應用的幾種事務處理機制、三種XA式、四種非XA式事務協議。
Spring框架支持Java Transaction API（JTA），這樣應用就可以脫離Java EE容器，轉而利用分布式事務以及XA協議。然而即使有這樣的支持，XA開銷是昂貴的，不穩定而且笨重不利於管理，不過一些其他的應用可以避免使用XA協議。
為了讓大家對所涉及的幾種分布式事務有所了解，我會分析七種事務處理模式，並
給出具體代碼實現。並且從安全或者穩定性入手倒序展示，可以看看從安全、穩定性出發，如何在一般場景下，保障數據高完整性和原子性。當然隨著話題的深入，
更多的說明以及限制就會出現。模式也可以從運行時開銷倒序展示。考慮到所有模式都是結構化或者學術性的，這一點有別於業務模型，因此我不打算展開業務用例
分析，僅僅關注每種模式其少部分代碼如何工作的。
盡管只有起初的三種模式涉及到
XA協議，不過從性能角度出發，這些模式或許無法滿足需求。考慮到這些模式無處不在，我不想做過多地擴展，只是對第一種模式做一個簡單的展示。讀完此文，
你可以了解可以用分布式事務做些什麼、不能做什麼以及如何、何時避免使用XA，何時必須使用。
分布式事務以及原子性
分布式事務涉及不止一個事務資源。比如，在關系資料庫和消息中間件之間通信的連接器，通常這些資源擁有類似begin()、rollback()、
commit()的API。在此，一個事務資源通常是一個工廠產品，這個工廠通常由底層平台提供：以資料庫為例，DataSource提供
Connection，或者Java Persistence API(JPA)的EntityManager介面；又如Java Message Service(JMS)提供的Session。
一個典型的例子，一個JMS消息觸發一次資料庫更新。此過程可以分解成一時間線，一個成功的交互順序是下面這樣：
開啟消息事務
接受消息
開啟資料庫事務
更新資料庫
提交資料庫事務
提交消息事務
如果資料庫出錯，比如更新時出現諸如違反約束的問題，一個理想的順序應該是下面這個樣子：
開啟消息事務
接受消息
開啟資料庫事務
更新資料庫失敗
回滾資料庫事務
回滾消息事務
在這個案例中，最後的回滾發生後消息返回給中間件，並且在某種程度返回的消息會被其他事務所接收。通常這是件好事，可能你並沒有對失敗做記錄。自動重試處理異常機制超出了本文的范疇。
以上兩種時間線中最重要的特性是它們的原子性，形成一個單一的邏輯事務單元，要麼都成功要麼都失敗。
那麼用什麼確保時間線會的順序呢？事務資源之間必須保持某種同步，一旦對某個數據源做提交，要麼都提交了，要麼都回滾。否者整個事務就不缺乏原子
性。之所以是分布式事務，是因為有多個數據源，沒有同步就沒有原子性。分布式事務技術和概念的核心問題都是圍繞資源的同步或者無法同步展開的。
前三種模式的以下討論都是基於XA協議，考慮到這三種模式分布廣泛，本文不會涉及太多的細節，倘若你熟悉XA模式或許願意直接跳到共享事務資源模式。
二階段提交完整XA協議
如果你需要近乎完美的防護
（close-to-bulletproof）確保你的應用事務在斷電後恢復以及伺服器崩潰，完整XA是不二之選。共享資源通常需要做事務同步，在此情況
下，它是一個採用XA協議協調處理過程的信息特殊的事務管理器。在Java領域，從開發者的角度看，這個協議是通過JPA
UserTransaction暴露給大家。
基於系統介面，XA作為一種促成科技（enabling technology）對多數開發人員不可見，因此他們需要知道XA在哪、促成什麼、耗損如何以及如何利用事務資源。事務管理器採用二階段提交（2PC）協議，在確保事務結束前所有資源採用同一個事務結果的同時，也會帶來性能耗損。
如
果是Spring促成的（Spring-enabled），應用會採用Spring的JtaTransactionManager以及Spring聲明式
事務管理，這樣會隱藏到了底層事務同步的具體細節。對於開發人員用沒用XA的差別就在於對工廠資源的配置:DataSource實例，以及應用的事務管理
器。本文會通過一個應用案例（atomikos-db項目）來揭示這個配置，資料庫實例和事務管理器僅是XA或者JTA特定的應用元素。
為了揭示此案例如何工作，在com.springsource.open.db.下運行這個單元測試。一個簡單的 MulipleDataSourceTests類僅是將數據插入兩個數據源中，並且採用Spring整合支持的特性對事務進行回滾，代碼見清單1：
清單1、事務回滾
@Transactional
@Test
public void testInsertIntoTwoDataSources() throws Exception {
int count = getJdbcTemplate().update(
"INSERT into T_FOOS (id,name,foo_date) values (?,?,null)", 0,
"foo");
assertEquals(1, count);
count = getOtherJdbcTemplate()
.update(
"INSERT into T_AUDITS (id,operation,name,audit_date) values (?,?,?,?)",
0, "INSERT", "foo", new Date());
assertEquals(1, count);
// Changes will roll back after this method exits
}
接著驗證這兩個操作是否同時回滾，代碼清單如清單2：
清單2、回滾驗證
@AfterTransaction
public void checkPostConditions() {
int count = getJdbcTemplate().queryForInt("select count(*) from T_FOOS");
// This change was rolled back by the test framework
assertEquals(0, count);
count = getOtherJdbcTemplate().queryForInt("select count(*) from T_AUDITS");
// This rolled back as well because of the XA
assertEquals(0, count);
}
更進一步理解Spring事務管理如何工作以及如何配置，請參看Spring參考指南。
一階段提交優化XA協議
許多事務管理器採用這種優化模式，可以避免單一事務資源下的2PC過度開銷，你的應用伺服器最好能夠判別此種情況。
協議和最終資源策略
多數XA事務管理器另一個特性是，不論是單一XA兼
容資源還是所有資源都XA兼容，事務管理器均能提供相同的恢復保障。它們是通過給資源排序，並且給非XA資源投票實現，倘若事務提交失敗，所有其他的資源
都能回滾。事務有近乎百分百的保障，但缺點是，倘若事務失敗，此時不會留下太多信息。換言之，如果要獲取這些信息，需要做一些額外的步驟，比如在一些高級
實現。
共享事務資源模式
這個模式不錯，系統所有的事務資源由一個相同的資源提供支持進而移除XA，降低系統的復雜度，提高吞吐量。當然不能拿來處理所有的用例，但卻是如XA般堅固，而且處理速度更加的快。共享事務資源模式作為一種保障存在與特定的平台和處理場景中。
一個簡單熟悉的例子就是共享一個資料庫的Connection，它存在於一個對象關系模型（ORM）控制項和一個JDBC控制項之間。Spring事務管理器就是如此，它支持ORM工具，比如Hibernate、EclipseLink以及Java Persistence API（JPA）。相同的事務能安全的跨越ORM和JDBC控制項之間，通常此事務是由service層受事務控制的執行方法所驅動的。
此模式的另外一個特點是，消息驅動的單個資料庫更新，如本文初始階段的簡單例子。消
息中間件系統需要存儲這些數據，通常是關系型資料庫。實現這種模式，需要將消息系統指定到相同的用於存儲業務數據的資料庫中。這種模式依賴消息中間件供應
商所提供的存儲策略細節，以便能夠將消息中間件配置在相同的資料庫中，並嵌入相同的事務處理。
不是所有的供應商都提供了此種模式，不過一種可替代，幾乎可以用於任何資料庫的方式，即利用Apache ActiveMQ的傳遞消息，並且插入一個存儲策略進入消息代理中。一旦你知道了其中的訣竅，配置起來很容易的，我會在本文的shared-jms-db 項目案例中演示。此模式的所用的代碼無需關注，它們會在Spring配置中得到聲明。
名為
的案例中，單元測試校驗所有與同步消息接收者相關的訊息。
方法接受兩個消息，接著利用消息插入兩條記錄到資料庫中。如果此方法退出，測試框架回
滾事務，這樣就能校驗消息和資料庫更新是否發生回滾，如清單3所示：
清單3、驗證消息和資料庫更新是否回滾
@AfterTransaction
public void checkPostConditions() {
assertEquals(0, SimpleJdbcTestUtils.countRowsInTable(jdbcTemplate, "T_FOOS"));
List<String> list = getMessages();
assertEquals(2, list.size());
}
配置文件最重要的部分就是ActiveMQ的持久化策略，連接消息系統和相同數據源作為業務數據，Spring JmsTemplate的flag標簽用來接收消息。清單4 展示了如何配置ActiveMQ持久化策略：
清單4、ActiveMQ持久化配置
<bean id="connectionFactory" depends-on="brokerService">
<property name="brokerURL" value="vm://localhost?async=false" />
</bean>
<bean id="brokerService" init-method="start" destroy-method="stop">
<property name="persistenceAdapter">
<bean>
<property name="dataSource">
<bean>
<property name="targetDataSource" ref="dataSource"/>
<property name="jmsTemplate" ref="jmsTemplate"/>
</bean>
</property>
<property name="createTablesOnStartup" value="true" />
</bean>
</property>
</bean>
清單5展示了Spring JmsTemplate中用來接收消息的flag標簽：
清單5、設置JmsTemplate事務應用
<bean id="jmsTemplate">
<!-- This is important... -->
<property name="sessionTransacted" value="true" />
</bean>
若 sessionTransacted不為true，JMS session transaction
API就無法被調用，消息接受者將無法回滾。最為重要的是，嵌入的代理包含一個特殊的async=false參數以及DataSource外包類，這樣就
可以確保ActiveMQ擁有同Spring一樣的事務JDBC Connection。
一個共享資料庫源可以由獨立的單個數據源組成，特別是這些數據源擁有同樣的RDBMS平台。企業級數 據庫供應商均提供同名概念（the
notion of
synonyms）支持，表可以作為一個同名（synonyms）聲明於多個schema中。藉助這個手段，分布在不同物理平台上的數據，可以均可
JDBC
client同意Connection事務管理。比如在一個真實的系統中，採用ActiveMQ共享資源模式實現，通常需要為消息和業務數據創建同名。
❸ 請問oracle xa是什麼
XA是X/Open DTP組織（X/Open DTP group）定義的兩階段提交協議，XA被許多資料庫（如Oracle和DB2）和中間件等工具(如CICS 和 Tuxedo).本地支持 。
X/Open DTP模型（1994）包括應用程序（AP）、事務管理器（TM）、資源管理器（RM）、通信資源管理器（CRM）四部分。在這個模型中，通常事務管理器（TM）是交易中間件，資源管理器（RM）是資料庫，通信資源管理器（CRM）是消息中間件。
一般情況下，某一資料庫無法知道其它資料庫在做什麼，因此，在一個DTP環境中，交易中間件是必需的，由它通知和協調相關資料庫的提交或回滾。而一個資料庫只將其自己所做的操作（可恢復）影射到全局事務中。
XA就是X/Open DTP定義的交易中間件與資料庫之間的介面規范（即介面函數），交易中間件用它來通知資料庫事務的開始、結束以及提交、回滾等。XA介面函數由資料庫廠商提供。通常情況下，交易中間件與資料庫通過XA 介面規范，使用兩階段提交來完成一個全局事務，XA規范的基礎是兩階段提交協議。
❹ mysql分布式事物xa跟普通的有什麼區別么
XA事務允許不同資料庫之間的分布式事務，如一台伺服器是MySQL資料庫的，另一台是Oracle資料庫的，又可能還有一台伺服器是SQL Server資料庫的，只要參與在全局事務中的每個節點都支持XA事務。
分布式事務需要多一次的PREPARE操作，待收到所有節點的同意信息後，再進行COMMIT或是ROLLBACK操作。
xaXXX操作就是要多一步 等待所有節點
❺ mysql普通事務和xa事務的區別
Java事務的類型有三種：JDBC事務、JTA（Java Transaction API）事務、容器事務。
普通事務只支持一個資料庫連接,不能跨越多個資料庫。默認的情況為自動提交事務，也就是說，每一條對資料庫的更新的sql語句代表一項事務，操作成功後，系統自動調用commit（）來提交，否則將調用rollback（）來撤消事務。
而XA事務支持在兩個或多個網路計算機資源上訪問並且更新數據，這些數據可以分布在多個資料庫上,如果計劃用 JTA 界定事務，那麼就需要有一個實現 javax.sql.XADataSource 、 javax.sql.XAConnection 和 javax.sql.XAResource 介面的 JDBC 驅動程序。一個實現了這些介面的驅動程序將可以參與 JTA 事務。一個 XADataSource 對象就是一個 XAConnection 對象的工廠,使用 UserTransaction.begin（）、 UserTransaction.commit（） 和 serTransaction.rollback（）進行操作
❻ 請教was配置資料庫中 連接池數據源和XA數據源區別
1.下載驅動的jar文件。
到microsoft官方網站下載sqlserver的jdbc驅動，其中主要有兩個文件：sqljdbc.jar和sqljdbc4.jar
將這兩個jar文件拷貝到websphere的安裝路徑下。
2.設置websphere的環境變數。
設置MSSQLSERVER_JDBC_DRIVER_PATH變數，指向官方驅動jar文件所存放的目錄。
3.新建JDBC提供程序。
資料庫類型：用戶定義的
實現類名： com.microsoft.sqlserver.jdbc.
com.microsoft.sqlserver.jdbc.SQLServerXADataSource〔用於XA數據源〕
類路徑： ${MSSQLSERVER_JDBC_DRIVER_PATH}/sqljdbc.jar 或是
${MSSQLSERVER_JDBC_DRIVER_PATH}/sqljdbc4.jar〔只適用於JDK1.6環境〕
❼ 什麼是XA標准
XA協議由Tuxedo首先提出的，並交給X/Open組織，作為資源管理器（資料庫）與事務管理器的介面標准。目前，Oracle、Informix、DB2和Sybase等各大資料庫廠家都提供對XA的支持。XA協議採用兩階段提交方式來管理分布式事務。XA介面提供資源管理器與事務管理器之間進行通信的標准介面。XA協議包括兩套函數，以xa_開頭的及以ax_開頭的。 以下的函數使事務管理器可以對資源管理器進行的操作： 1）xa_open,xa_close：建立和關閉與資源管理器的連接。 2）xa_start,xa_end：開始和結束一個本地事務。 3）xa_prepare,xa_commit,xa_rollback：預提交、提交和回滾一個本地事務。 4）xa_recover：回滾一個已進行預提交的事務。 5）ax_開頭的函數使資源管理器可以動態地在事務管理器中進行注冊，並可以對XID(TRANSACTION IDS)進行操作。 6）ax_reg,ax_unreg；允許一個資源管理器在一個TMS(TRANSACTION MANAGER SERVER)中動態注冊或撤消注冊。
❽ XA「大師，是什麼意思
就是什麼都會的人。反正不是機器人。分析師。
❾ 什麼是xa事務
分布式事務，X/Open組織（即現在的Open Group）定義了分布式事務處理模型。X/Open DTP模型（1994）包括應用程序（AP）、事務管理器（TM）、資源管理器（RM）、通信資源管理器（CRM）四部分。一般，常見的事務管理器 （TM）是交易中間件，常見的資源管理器（RM）是資料庫，常見的通信資源管理器（CRM）是消息中間件。為表述方便起見，在本文中直接以其常見表現形式 進行描述。
❿ c# SQL跨資料庫事務問題。
資料庫建同義詞 ，可以不需要 跨資料庫 這樣插入的。
以下示例首次創建將在此後的示例中使用的同義詞。
USE tempdb;
GO
CREATE SYNONYM MyAddressType
FOR AdventureWorks.Person.AddressType;
GO
以下示例將行插入到由 MyAddressType 同義詞引用的基表。
USE tempdb;
GO
INSERT INTO MyAddressType (Name)
VALUES ('Test');
GO