Gemfire 分布式事务介绍文档
shardingjdbc分布式事务原理
shardingjdbc分布式事务原理ShardingJDBC是一种开源的Java数据库中间件，用于实现分布式数据库的数据分片和分布式事务。
分布式事务是指涉及多个数据库的事务操作，需要保证多个数据库之间的数据一致性和事务的原子性。
在分布式系统中，数据分片是将数据按照某种规则分散到多个数据库中的过程。
ShardingJDBC通过数据分片算法将数据按照某种规则分配到不同的数据库中，实现数据的分布式存储和查询。
例如，可以根据用户ID对数据进行分片，将用户ID为1-100的数据存储在数据库A中，用户ID为101-200的数据存储在数据库B中。
在分布式事务中，多个数据库之间的事务操作需要保证原子性和一致性。
ShardingJDBC通过协调器和多个数据库的协作实现分布式事务的原子性和一致性。
当一个事务涉及到多个数据库时，ShardingJDBC将事务操作分为多个子事务，每个子事务对应一个数据库。
协调器负责协调和管理多个子事务的执行，确保所有子事务要么全部成功提交，要么全部回滚。
具体的分布式事务流程如下：1. 应用程序发起分布式事务请求。
2. ShardingJDBC的协调器接收到事务请求后，生成全局事务ID，并将该事务ID与子事务进行关联。
3. 协调器向各个数据库的本地事务管理器发送事务开始的请求。
4. 各个数据库的本地事务管理器收到事务开始的请求后，开始执行本地事务，并生成本地事务ID。
5. 本地事务管理器将本地事务ID和全局事务ID进行关联，并将本地事务执行结果返回给协调器。
6. 协调器收到各个数据库的本地事务执行结果后，根据结果进行判断。
如果所有子事务都执行成功，则向各个数据库的本地事务管理器发送事务提交的请求；如果有任何一个子事务执行失败，则向各个数据库的本地事务管理器发送事务回滚的请求。
7. 各个数据库的本地事务管理器收到事务提交或回滚的请求后，执行相应的操作，并将操作结果返回给协调器。
8. 协调器收到各个数据库的事务提交或回滚的结果后，根据结果判断整个分布式事务的执行结果。
ignite 分布式计算
ignite 分布式计算Ignite 分布式计算是一种强大的计算框架，它能够帮助用户高效地处理大规模数据集。
本文将介绍 Ignite 分布式计算的基本原理以及其在实际应用中的优势。
Ignite 分布式计算采用内存计算的方式，以提高计算速度和效率。
它将数据存储在内存中，并通过分布式计算节点对数据进行并行处理。
这种方式使得 Ignite 分布式计算能够快速地处理大规模数据集，从而加速计算过程。
Ignite 分布式计算的一个重要特点是其灵活性。
它可以与各种数据存储系统和计算引擎无缝集成，如 Hadoop、Spark 等。
通过与这些系统的集成，Ignite 分布式计算能够利用它们的优势，进一步提高计算性能和效率。
除了高性能和灵活性，Ignite 分布式计算还具有强大的容错能力。
它采用了数据复制和故障恢复机制，以保证计算过程的可靠性。
当计算节点出现故障时，Ignite 分布式计算会自动将任务重新分配给其他节点，从而避免计算中断和数据丢失。
在实际应用中，Ignite 分布式计算被广泛应用于各个领域。
例如，在金融行业，Ignite 分布式计算可以用于实时风险分析和交易处理。
在电力行业，它可以用于智能电网的实时监控和优化。
在物流行业，它可以用于路径规划和运输调度。
无论是处理大规模数据集还是实时计算，Ignite 分布式计算都能够提供高效的解决方案。
Ignite 分布式计算是一种强大且灵活的计算框架，它能够帮助用户高效地处理大规模数据集。
通过其高性能、灵活性和容错能力，Ignite 分布式计算在实际应用中展现出巨大的潜力。
无论是金融、电力还是物流行业，Ignite 分布式计算都能够为用户提供高效、可靠的解决方案。
它的出现不仅推动了分布式计算的发展，也为各个行业带来了巨大的变革和机遇。
OceanBase1.0的分布式事务讲解
盘的原子性操作和硬件本身有关，磁盘一般是一个512 字节的块写入是原子的，SSD 一般是4KB 的块写入是原子的。
用一个数据结构的例子说明这种原子性实现机制。
struct Balance {int accountA;int accountB;};Balance * x ＝new Balance();上面是C++ 的结构体，表示了两个账户 A 和 B 的余额。
如果从 A 转账5 元给B，对应的C++ 代码如下：x->accountA -= 5;x->accountB += 5;上面的代码不是原子的，在两条语句中间，如果另一个线程读取accountA 和accountB 的值，会发现转账操作只执行了一半。
如果使用下面的代码，就可以保证无论什么时候读取，都不会读到转账执行了一半的情况：Balance * tmp = new Balance();tmp->accountA = x->accountA - 5;tmp->accountB = x->accountB + 5;x = tmp;操作的生效时间是x = tmp;语句，单一变量的赋值操作是原子的，保证了整个转账操作是原子的。
使用日志实现原子性（Atomicity）上面基于原子性操作的实现方法在数据结构中很常用，但是现在数据库系统都是使用日志技术（log）实现原子性（Atomicity），因为日志技术解决原子性的方法更灵活，还能同时解决了事务的持久性（Durability）需求，而且比直接持久化数据有更好的性能，所以几乎所有的数据库系统都采用了日志技术（log），甚至还包括文件系统、队列系统等。
使用log 时，先把整个事务的操作编码成连续的日志信息，再把日志信息写入持久化设备，当日志成功写入后，就是保证事务原子性成功的时机。
以上面的转账操作为例，编码出的日志信息如下：<accountA, balance, -5>, <accountB,, balance, +5>当上面的信息持久化成功后，数据库系统再会修改两个帐户的数据，而且帐户数据本身持久化到硬盘的时机可以延后到任意时刻，因为即使数据没有持久化前就宕机了，系统重启后还是可以从log 中将上面的转账操作恢复出来。
Seate分布式事务解决方案
Seate分布式事务解决⽅案Seata是阿⾥开源的⼀个分布式事务框架。
Seata主要有两种分布式事务实现⽅案，AT及TCCAT模式主要关注多 DB 访问的数据⼀致性，当然也包括多服务下的多 DB 数据访问⼀致性问题TCC 模式主要关注业务拆分，在按照业务横向扩展资源时，解决微服务间调⽤的⼀致性问题AT模式/MT模式Seata AT模式是基于XA事务演进⽽来的⼀个分布式事务中间件，XA是⼀个基于数据库实现的分布式事务协议，本质上和两阶段提交⼀样，需要数据库⽀持，Mysql5.6以上版本⽀持XA协议，其他数据库如Oracle，DB2也实现了XA接⼝。
AT不依赖与数据库本⾝对协议的⽀持，当然也不需要数据库⽀持 XA 协议。
这点对于微服务化的架构来说是⾮常重要的：应⽤层不需要为本地事务和分布式事务两类不同场景来适配两套不同的数据库驱动。
原理Transaction Coordinator (TC)：事务协调器，维护全局事务的运⾏状态，负责协调并驱动全局事务的提交或回滚。
Transaction Manager (TM)：控制全局事务的边界，负责开启⼀个全局事务，并最终发起全局提交或全局回滚的决议。
Resource Manager (RM)：控制分⽀事务，负责分⽀注册、状态汇报，并接收事务协调器的指令，驱动分⽀（本地）事务的提交和回滚。
使⽤1. 创建Seata TC Server服务Seata TC Server的 db 数据库为：（1）global_table ：the table to store GlobalSession data（2）branch_table：the table to store BranchSession data（3）lock_table：the table to store lock data2. 使⽤⽅数据库增加undo_log表：⽤于分⽀事务的回滚3. ⽅法上增加@GlobalTransactional注解执⾏过程图特别注意的是：1. 回滚时通过 XID 和 Branch ID 查找到相应的 UNDO LOG 记录并校验。
Coherence-GemFire Differences
• Both products can easily saturate available network bandwidth when running
extreme situation tests
• Steady state (post initialization) raw performance ( gets and puts ) tend to
Coherence:
" Recommends very small JVM heap sizes (<1GB) per partition, resulting in many more nodes to manage per cluster
/docs/cd/E14526_01/coh.350/e16628/docerrata.htm#sthref72
Confidential
Queries Coherence has added a query language, CohQL in release 3.6 which is comparable to GemFire s support of the OMG s OQL query language (since v 5.7). Both support command line interfaces for interacting with data • Coherence – query command • GemFire – gfsh command Both support the concept of Continuous Queries GemFire:
XTS 支付宝分布式事务学习指南
@潇桐 @柳成
支付宝-成都应用研发中心-创新支付工具组-卡券平台
V1.0.8
修订历史
版本号 1.0.0 1.0.1 1.0.2
修订人 @潇桐 @柳成 @柳成
内容提要 初建文档，完成 XTS 实例分析和配置部分编写 增加 XTS 理论基础部分 1. 2. 增加 XTS 源码浅析部分 完成排版
II
1
概
述
1
概
述
XTS（eXtended Transaction Service）框架[1]，是支付宝的一个极为核心而且复杂的分布式事务技术 框架，在支付宝有广泛地使用，主要用于保证在账务、资金等操作的事务一致性，因此 XTS 框架足以称为 支付宝分布式事务框架。因为其应用场景和理论知识的复杂性，使得整个框架的配置和理解不那么简单和 易学，因此不少新同学在理解 XTS 和配置 XTS 上走了很多弯路。本文是作者在学习 XTS 的过程中思考和 总结的结果，主要对 XTS 的理论基础和基本概念（@柳成 整理） 、XTS 的实例分析和配置使用方法（@潇 桐 整理） 、XTS 源码浅析（@柳成 整理）这三个方面来对 XTS 进行一个较为全面的入门学习，希望能在 某些方面能够解答新人学习时的疑惑。
v108xts支付宝分布式事务学习指南修订历史版本号修订人内容提要修订日期100初建文档完成xts实例分析和配置部分编写20140722101增加xts理论基础部分20140723102增加xts源码浅析部分完成排版20140724103对文档细节提出疑问和修订给出修改意见20140725104针对修改意见完成细节修改20140725105修正242中几处错误感谢宾雨指正20140729106对一种recover的特殊情况进行考虑总结出答案并添加在44感谢宾雨的讨论20140730107重新绘制242中异库模式下recover回查情况的箭头指向并作出说明感谢虞卿指正20140731108重新绘制242中所有图中二阶段的流程20140830iixts分布式事务原理21分布式事务22为什么需要xts23支付宝分布式事务基础模型231xopendtp模型232两阶段提交协议233最末参与者优化lpo24xts基本概念和分布式事务执行流程241事务发起者参与者242发起方参与者不同模式下执行流程243xts异常处理工作原理1425小结xts实例分析和配置使用1631xts里的基本概念1632同库模式16321编写action16322编写activity1833异库模式2434理解同库和异库模式2635参与者的localremote模式2836嵌套事务2837模式小结2938详解配置同库模式xts主要流程源码浅析3341发起方流程一阶段3342参与者流程一阶段3843参与者提交回滚过程二阶段4244xts恢复机制执行流程4745小结xtsextendedtransactionservice框架是支付宝的一个极为核心而且复杂的分布式事务技术框架在支付宝有广泛地使用主要用于保证在账务资金等操作的事务一致性因此xts框架足以称为支付宝分布式事务框架
分布式事务- TCC编程式模式
分布式事务- TCC编程式模式一、前言严格遵守ACID的分布式事务我们称为刚性事务，而遵循BASE理论（基本可用：在故障出现时保证核心功能可用，软状态：允许中间状态出现，最终一致性：不要求分布式事务打成中时间点数据都是一致性的，但是保证达到某个时间点后，数据就处于了一致性了）的事务我们称为柔性事务，其中TCC编程模式就属于柔性事务，本文我们来阐述其理论。
二、TCC编程模式TCC编程模式本质上也是一种二阶段协议，不同在于TCC编程模式需要与具体业务耦合，下面首先看下TCC编程模式步骤:∙所有事务参与方都需要实现try,confirm,cancle接口。
∙事务发起方向事务协调器发起事务请求，事务协调器调用所有事务参与者的try方法完成资源的预留，这时候并没有真正执行业务，而是为后面具体要执行的业务预留资源，这里完成了一阶段。
∙如果事务协调器发现有参与者的try方法预留资源时候发现资源不够，则调用参与方的cancle方法回滚预留的资源，需要注意cancle方法需要实现业务幂等，因为有可能调用失败（比如网络原因参与者接受到了请求，但是由于网络原因事务协调器没有接受到回执）会重试。
∙如果事务协调器发现所有参与者的try方法返回都OK，则事务协调器调用所有参与者的confirm方法，不做资源检查，直接进行具体的业务操作。
∙如果协调器发现所有参与者的confirm方法都OK了，则分布式事务结束。
∙如果协调器发现有些参与者的confirm方法失败了，或者由于网络原因没有收到回执，则协调器会进行重试。
这里如果重试一定次数后还是失败，会怎么样那？常见的是做事务补偿。
蚂蚁金服基于TCC实现了XTS（云上叫DTS），目前在蚂蚁金服云上有对外输出，这里我们来结合其提供的一个例子来具体理解TCC的含义，以下引入蚂蚁金服云实例：“首先我们假想这样一种场景：转账服务，从银行 A 某个账户转 100 元钱到银行 B 的某个账户，银行 A 和银行 B 可以认为是两个单独的系统，也就是两套单独的数据库。
ignite 分布式计算
ignite 分布式计算一、分布式计算概述分布式计算是一种通过网络连接多个计算机共同完成计算任务的技术。
它能有效提高计算性能、扩展性和容错能力，广泛应用于大数据、机器学习、科学计算等领域。
二、Ignite架构介绍1.Apache Ignite是一个高性能、轻量级的分布式计算框架，起源于Apache Project Voldemort。
2.Ignite支持多种计算模型，如内存计算、流处理、图计算等。
3.Ignite提供了丰富的API和工具，便于开发者进行分布式应用的开发。
三、Ignite的优势和特点1.高性能：Ignite直接在内存中执行计算任务，避免了磁盘I/O瓶颈。
2.易于扩展：通过添加更多的节点，Ignite能线性扩展计算能力。
3.容错性：Ignite支持故障转移和负载均衡，确保系统在高可用性条件下运行。
4.支持多种计算模型：Ignite能满足不同类型的计算需求，如实时数据处理、大规模数据分析等。
四、Ignite的应用场景1.实时数据处理：金融、物联网、在线广告等领域。
2.大规模数据分析：推荐系统、图像识别、自然语言处理等。
3.分布式事务处理：分布式数据库、分布式锁、分布式缓存等。
五、如何使用Ignite进行分布式计算1.引入Ignite依赖：在项目中添加Apache Ignite依赖。
2.创建Ignite集群：初始化Ignite实例，配置集群参数。
3.编写分布式任务：使用Ignite API编写分布式计算逻辑。
4.部署和运行：将应用程序部署到集群中的节点上，进行分布式计算。
六、总结与展望Apache Ignite作为一个高性能、轻量级的分布式计算框架，为开发者提供了便捷的分布式计算解决方案。
分布式事务seata的使用方法
分布式事务seata的使用方法小伙伴！今天咱们来唠唠分布式事务里的Seata怎么用哈。
Seata是个超酷的分布式事务解决方案呢。
那第一步呀，咱得把Seata的服务端给搭建起来。
这就像是盖房子打地基一样重要哦。
你要去Seata的官方仓库下载对应的版本，然后按照文档里的说明去配置它的一些基本参数，像存储模式啦，要是用数据库存储事务信息，就得把数据库相关的连接信息啥的配置得妥妥当当。
接着就是在咱们的项目里引入Seata的客户端啦。
这时候就看你用啥开发语言啦，如果是Java项目，就把Seata的Java客户端依赖加到你的项目里。
这个过程就像是给你的项目注入一股神奇的力量，让它能处理分布式事务啦。
在代码里呢，你得对那些需要参与分布式事务的方法做一些特殊的标记。
比如说在Spring Boot项目里，你可以用注解的方式。
像@GlobalTransactional这个注解，就像是给方法穿上了一件特殊的“分布式事务外套”，告诉Seata这个方法是要在分布式事务的管控之下的。
还有哦，不同的数据库操作在Seata里也有一些小讲究。
比如说，你要是对数据库做更新操作，Seata会帮你记录操作前后的状态，就像一个贴心的小管家。
如果在分布式事务执行过程中出了岔子，它就能根据这些记录把数据恢复到正确的状态。
在配置Seata客户端的时候呀，要记得把服务端的地址告诉它，这样客户端才能找到服务端这个“大管家”来协调分布式事务呢。
这就好比你要去朋友家玩，得知道朋友家的地址一样。
而且呀，Seata在处理分布式事务的时候，会涉及到很多的角色，像事务协调器、事务参与者之类的。
每个角色都有自己的任务，它们就像一个团队一样默契配合。
咱们在使用的时候不用太担心这些角色内部复杂的交互，只要按照规则配置好，Seata就会自动让它们好好工作啦。
总之呢，使用Seata虽然一开始可能觉得有点小复杂，但是只要你按照步骤一步一步来，就像搭积木一样，慢慢就能把分布式事务管理得井井有条啦。
全局事务分布式事务（GlobalTransactionAdistributedtransa。。。
全局事务分布式事务（GlobalTransactionAdistributedtransa。
这⾥参考的是Oracle对于XA的⽀持，其他的应该雷同吧。
⼀个典型的全局性事务的架构如下，通常来说TM会集成在Application Server（例如weblogic server）中。
这种TM也叫做external TM，区别于在MySQL DBMS或者Oracle DBMS中的管理本地事务的TM。
资源管理器(RM):⽤户提供通向事务的途径。
数据库服务器（例如上⾯的Oracal DBMS）是⼀个种资源管理器。
该管理器必须提交or回滚由RM管理的事务。
事务管理器(TM):⽤于协调作为⼀个分布式事务的⼀部分事务。
通常XA的相关操作都在这⾥进⾏，⽽对于Client⽽⾔是透明的，TM（或许是个进程）通常是由TPM（ transaction processing monitor，Texudo就有这个组件，所以Texudo也就本能地⽀持了全局事务）提供。
对于Client App⽽⾔，所有的Global Transaction都应该通过TM进⾏（在ORACLE中，是名字为TX的⼀组接⼝函数），TM再与RM通过XA 接⼝（Oracle有提供这组函数）进⾏接洽。
⽽所有的普通的针对同⼀个数据库的事务可以直接通过Native Interface进⾏。
在Oracle的⽂档⾥，⼀个Global Transaction被分为多个Branch。
A branch is a unit of work contained within one RM. In the case of Oracle Database, each branch maps to a local transaction inside the database server.理解全局性事务的关键是理解两阶段提交：The Oracle XA library interface follows the two-phase commit protocol. The sequence of events is as follows:1. In the prepare phase, the TM asks each RM to guarantee that it can commit any part of the transaction. If this is possible, then the RMrecords its prepared state and replies affirmatively to the TM. If it is not possible, then the RM may roll back any work, reply negatively to the TM, and forget about the transaction. The protocol allows the application, or any RM, to roll back the transaction unilaterally until the prepare phase completes.2. In phase two, the TM records the commit decision and issues a commit or rollback to all RMs participating in the transaction. TM canissue a commit for an RM only if all RMs have replied affirmatively to phase one.下⾯的⼀个例⼦是从Oracle的JDBC⽂档⾥搞出来的。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
GemFire分布式事务Gemfire有两个机制保证区域中的数据一致性:Distributed T ransaction, 和Conflict d etect, o peration a tomicityACID比较原子性传统的数据库技术为了达到原子性提供了行级” Two Phase Locking Protocol”来协调交叉事务，交叉事务是指两个事务重叠在一起，持有写锁防止读事务进行，直到所有的改变完成。
要么全做要么不做的事务操作。
如果在事务中发生了问题，比如关系约束，存储限制，读锁保护等，解决这些问题常常是回滚到事务前。
回滚需要释放写锁。
一般情况下，传统的分布式数据库技术实现要么全做要么不做的事务操作是” Two P hase C ommit P rotocol”，需要所有的进程参与到事务当中来同意执行事务或者放弃事务。
Gemfire实现要么全做要么不做的事务通过事务状态线程来收集所有的事务变化。
条目的变化集以原子状态保留在留存系统。
已经获得的保存防止其他的交叉事务执行。
既然Gemfire是分布式的，那么他的事务状态也被以批处理的方式发送到合适的虚机上，然后在事务状态过程中处理，防止虚机出现处理事务故障，所有更新完成之后，在本地和远程上的留存资源全被释放。
回滚一个事务与丢弃掉事务状态一样简单。
读并不使用留存系统使得读非常地快，这种系统类似于Muliversion C oncurrency C ontrol 系统，在这个算法中每一个线程都能够写一个新数据条目而且不影响读的性能，与其类似，其他的读操作也看到的是最新版本的数据条目。
一致性数据库的一致性常常被描述成为Referential Integrity，通过主键和外键的约束来描述表之间的引用。
一个数据库事务更新多个表的多个列必须保证所有的更新全部完成来维护一致性。
对于Gemfire，应用在Region和他的Entry之间控制一致性的类型和数量。
Gemfire 事务当提交时使用留存系统来保障每个区域所有条目的变化在提交时被处理。
那么当事务对条目做出改变时，一旦相应的留存系统被获取，冲突检测便运行，他将保障更新操作在同一个事务状态中调度条目。
隔离Gemfire事务发生在进程和线程级别，意味着事务的改变通过进程级的线程做出，直到提交阶段才可见，提交之后才与其他的线程共享事务的数据。
关系型数据库的事务隔离是在每次JDBC连接中做出的。
Gemfire读是volatile瞬时的。
意味着他们并不使用锁。
这样就使得读响应其他条目的操作非常地快，他也允许同时进行事务写处理，两者互相并不冲突。
可见性关系到隔离，也是原子级操作。
在读操作中已经提交的写是可见的。
在读事务中提供了重复读隔离，意味着一旦一个已经提交的值引用被读，将要返回一个相同的引用。
如果事务用一个键写一个值，此时这个键已经被读了，后续的读将要返回事务引用。
如果这个值已经被提交到Region中，读返回了这个值的一个引用。
强烈反对直接到Region中修改这个值，特别是他们处在事务之中时，因为他们在提交之前是立即可见的，即使他们改变了已经提交的状态。
接下来的例子详解了这种反模式操作:Region<Integer, S tringBuilder> r1 = ...;CacheTransactionManager t xmgr = ...;try {txmgr.begin();Integer k ey = I nteger.valueOf(1);StringBuilder v = r1.get(key);v.append(" a dded s tuff"); // B AD!!! This c hange i s n ot i solated f rom o thertransactions!r1.put(key, v);mit();} c atch (CommitConflictException c onflict) {txmgr.rollback();}下面例子纠正了上面的错误:Region<Integer, S tringBuilder> r1 = ...;CacheTransactionManager t xmgr = ...;try {txmgr.begin();Integer k ey = I nteger.valueOf(1);StringBuilder v = r1.get(key); // a ssume v i s n ot n ullStringBuilder n ewV;synchronized (v) {newV = n ew S tringBuilder(v.toString());}newV.append(" a dded s tuff");r1.put(key, n ewV);mit();} c atch (CommitConflictException c onflict) {txmgr.rollback();}有两个重要的改进:1. 新值创建后保存在区域中，这个值被保存在事务上下文中，如果没有冲突，他便顺利提交。
2. StringBuilders并不是同步的，当拷贝数据时，需要同步锁保证视图内容的一致性。
Gemfire 缓存读拷贝任何一个在事务中将被改变的值，可以自动被设定成读拷贝或者通过CopyHelper 手工创建一个拷贝。
另外一个重要的方面就是已提交数据的原子可见性；在被应用之前或者处于传送提交中事务变化的可见性。
比如两个键“1”和“2”的值都从A变成B，在另一线程看来，可能“1”的值为B而“2”的值为A。
这种选择牺牲了原子可见性，读不妨碍写，写也不妨碍读。
关系型数据库的Two-‐phase l ocking在读和写时都需要额外的开销，牺牲了性能来达到原子隔离的目的。
用这样的技术，在所有行都写完之后才释放锁，提交过程中的读是不可能的。
持久性利用磁盘存储实现的Mysql和Oracle比Gemfire更加的持久，关系型数据库使用磁盘存储实现了持久性。
Gemfire当前事务的持久性只是与非持久化区域的耐久性有关。
不同成员之间的拷贝数越多，持久性就越高。
没有持久化，持久性将成为保障RAM，Network 和VM可靠性的一个问题。
其他重要不同点语言一个关系型数据库事务用SQL定义事务操作。
Gemfire事务用java写操作。
Java语言覆盖范围非常广，但是只有Gemfire操作是事务的，但并不是所有的Region 操作是事务的，如Region.destroyRegion。
乐观锁机制Gemfire事务在提交操作时运行了数据锁机制和一致性检查，假设乐观地认为事务之间有很少的冲突。
而关系型数据库是悲观锁，在事务早期就加锁。
从性能角度比较，乐观锁性能更快，因为很少有阻塞。
冲突检测Gemfire提供了写-‐写冲突检测，来保证事务更新时候被调度的条目没有任何的变化。
当执行读的时候Gemfire优先考虑写，写完成之后读才被调度。
通过检查标识符来做出改变。
共享和嵌套事务在某些数据库中，嵌套事务是被允许的。
Gemfire不允许嵌套，特别是调用了事务的时候在线程之间共享事务状态是不被允许的。
主要是因为没有相关的对象来代表事务状态。
事件通告Gemfire通过CacheListener, CacheWriter 和 TransactionListener三个接口来通告事务条目操作的事件。
CacheListener, CacheWriter每条目投递事件，TransactionListener每事务投递事件，反映在跨Region的事务中的所有操作上，和基于每键的合并操作上。
提交顺序以下是Gemfire 提交顺序如下：1.获取分布式留存资源提交集所有键的消息被发送到留存VM中。
整个的留存阶段是原子的。
只有整个集可用留存才被授权。
获得留存资源出现故障将导致CommitConflictException。
一旦失败，配置事务监听器将要被通告这个失败的提交。
留存资源管理器在第一个运行提交的缓存服务器中创建。
避免了留存信息在其他节点重复创建。
这个技术提高了事务的吞吐能力。
2.本地冲突检测冲突检测保证提交集中的条目没有变化。
事务失败抛出CommitConflictException。
这个检测沿着以前的步骤保证在事务内部将要更新的对象没有任何变化。
以前的留存步骤被设计成允许冲突检测依赖本地标识映射分布式状态。
使检测变得非常快。
所以标识符检测非常重要。
3.提交集信息提交集信息分布在涉及事务的每一个成员节点。
Gemfire基于成员和受影响的Region来计算成员集。
使用这个信息，消息被设计成批量处理大规模事务到单一的发送操作之中，成员之间互相优化来移除不必要的Region数据。
提交集的接受者完全去序列化这条消息。
Gemfire分布式这个提交集基于distribution scope configuration。
对于提交到Scope.DISTRIBUTED_NO_ACK Region 的改变，提交集立即被处理否则就会被第二个提交集所替换掉。
4.提交信息一旦所有的提交集信息被发送。
一个最终的提交信息被发送给Scope.DISTRIBUTED_ACK R egion的所有成员。
每一个接受了这个提交信息的成员处理这个提交集，条目应用到所有的缓存和任何一个关联Region的CacheListener，CacheListeners将被调用以同样的顺序。
所有的提交消息的接收者回应这个ACK。
从性能角度来讲，在等待ACK之前所有消息被发送是非常重要的一环。
对于要求高事务可靠性，Scope.DISTRIBUTED_ACK是重要的，提交操作等待每一个节点处理事务改变，发送线程能够感知到任何的问题，Scope.DISTRIBUTED_NO_ACK不具备保障事务的高可靠性，因为提交集被立即应用，发送线程并不感知任何的处理问题。
5.应用本地缓存一旦分布式应用成功了，提交集将被应用到本地缓存。
任何的挂起超时或者清楚操作将要与当前执行的线程冲突。
6.完成阶段配置的监听器将要被调用。
提交方法返回。
Gemfire和JTA的关系J2EE协议和J2EE应用服务器实现了分布式事务利用JTA A PI。
Gemfire参与了JTA 事务规范的制定和实现， 实现了javax.transaction.Synchronization接口。
当Gemfire类被加载，就启动javax.transaction.TransactionManager的搜索。
如果存在或者一个javax.transaction.Transaction事务正在进行，Gemfire事务便开启，Gemfire事务在TransactionManager注册并且每一个Region.Entry 操作都被Gemfire事务所收集。