litx 是一个基于补偿的轻量级分布式事务框架。（目前只支持 dubbo，未来计划支持 http 等其他 rpc 调用的补偿）
对代码逻辑无侵入
和 spring 事务无缝结合（内部实现是集成 spring 的事务管理器，靠 @transactional标注开启）
自动回滚补偿接口
如回滚异常提供 hook 接口可供扩展，当回滚失败时，可以拿到数据自行可作处理。
Quick Start
也可以参考 litx-test 的测试用例，其工程演示了在 dubbo 环境下的测试情况。
也可参照以下代码进行快速配置
第一步 定义你相关接口的 rollback 接口。假设你的 dubbo 方法为 submitOrder，回滚接口命名规则为rollbackSubmitOrder，请求参数定义为你submitOrder的返回类型。加上spring的事务标注@Transactional 并且再你的接口上加入 @Compensable标注
public interface DemoService {
@Compensable
String test1();
@Compensable
String test2();
void rollbackTest1(String str);
void rollbackTest2(String str);
}
第二步 spring 配置中加入以下定义
<bean id="litxDubboDefinationScanner" class="com.thebeastshop.litx.spring.LitxDubboDefinationScanner"/>
第三步 替换默认的 spring 事务管理器
<bean name="transactionManager" class="com.thebeastshop.litx.transaction.LitTransactionManager"> <property name="dataSource" ref="dataSource"/> </bean>
如果你想处理回滚异常的数据 请定义自己的类，实现 RollbackInvokeHook 接口。并把自己的类注册到 spring 容器内就可以。litx 启动的时候会自动扫描到。
测试用例说明
测试工程提供了一个 dubbo-provider，首先得启动他，用 Runner 的 main 启动（数据源配置请重新配置），然后启动 dubbo-consumer consumer 的 test 用例演示了一个用例：consumer 先调用 provider 的 test1，再调用 test2。test2 代码里主动抛错。test1 回滚，test1 回滚的时候主动抛错，然后被 consumer 自定义的 hook 捕获到。
-
ShardingSphereTransactionManager SPI 名称 详细说明 ShardingSphereTransactionManager 分布式事务管理器 已知实现类 详细说明 XAShardingSphereTransactionManager 基于 XA 的分布式事务管理器 SeataATShardingSphereTransactionManager 基于 Seata 的分
-
ShardingSphere-Proxy 接入的分布式事务 API 同 ShardingSphere-JDBC 保持一致，支持 LOCAL，XA，BASE 类型的事务。 XA 事务 ShardingSphere-Proxy 原生支持 XA 事务，默认的事务管理器为 Atomikos。 可以通过在 ShardingSphere-Proxy 的 conf 目录中添加 jta.properties 来定
-
通过 Apache ShardingSphere 使用分布式事务，与本地事务并无区别。 除了透明化分布式事务的使用之外，Apache ShardingSphere 还能够在每次数据库访问时切换分布式事务类型。 支持的事务类型包括 本地事务、XA事务 和 柔性事务。可在创建数据库连接之前设置，缺省为 Apache ShardingSphere 启动时的默认事务类型。
-
背景 数据库事务需要满足 ACID（原子性、一致性、隔离性、持久性）四个特性。 原子性（Atomicity）指事务作为整体来执行，要么全部执行，要么全不执行。 一致性（Consistency）指事务应确保数据从一个一致的状态转变为另一个一致的状态。 隔离性（Isolation）指多个事务并发执行时，一个事务的执行不应影响其他事务的执行。 持久性（Durability）指已提交的事务修改数据会被持久
-
单文档原子性可满足大多数业务需求 在 MongoDB 中，对单个文档的操作是原子操作。 由于 MongoDB 文档数据模型，一个文档中通过嵌入式的文档和数组来表示传统关系数据库模型中的一对一、一对多关系，而不是通过文档之间的复杂关系来描述业务需求中的一对一、一对多关系。 所以单文档原子性可以满足实际生产中大多数关于事务的需求。 对于需要对多个文档（在单个或多个集合中）进行原子读写的情况，Mongo
-
问题内容： 是否有一个提供发布/订阅模式的Java轻量级框架？ 一些理想的功能 支持泛型 向发布者注册多个订阅者 API主要是接口和一些有用的实现 完全不需要内存，持久性和事务保证。 我了解JMS，但这对我来说太过分了。发布/订阅的数据是文件系统扫描的结果，扫描结果被馈送到另一个组件进行处理，然后在将其馈给另一个组件之前进行处理，依此类推。 编辑：所有在同一过程中。bean的PropertyCha
-
两阶段提交协议 通常在复杂场景下是不推荐使用的，除非是非常简单的场景，非常容易提供回滚，而且依赖的服务也非常少的情况。 这种实现方式会造成代码量庞大，耦合性高。而且非常有局限性，因为有很多的业务是无法很简单的实现回滚的，如果串行的服务很多，回滚的成本实在太高。 本地消息表 这种实现方式的思路，其实是源于ebay，后来通过支付宝等公司的布道，在业内广泛使用。其基本的设计思想是将远程分布式事务拆分成一
-
分布式事务基于 JTA/XA 规范实现 1。 两阶段提交： 1. 本功能暂未实现 ↩