❶ 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