概述

分布式事务可以简单地分解为两部分：“分布式”与“事务”，即一种分布式系统中横跨多个服务的事务。相比传统的数据库本地事务，分布式事务受限于CAP定理，往往是一种“阉割”版的事务，因而难以满足传统事务4大特性ACID(Atomicity, Consistency, Isolation, Durability)的全部要求。 而处理分布式事务的处理方案多种多样，也各有利弊，下面将对常见几种方案进行逐一阐述。

概述

为了进一步兼容Java，我们Groovy核心团队决定从Groovy 4.0.0开始支持Switch Expression、Record Class、Sealed Class等Java语言特性。值得注意的是，即使Groovy 4.0.0运行在Java 8上，这些新特性依然可以使用。除了兼容Java语言特性外，Groovy自身也新增了不少实用的新特性，比如增强Range、支持TOML、Java化（@POJO）、GINQ（Groovy-Integrated Query）等。

背景介绍

C#最先引入LINQ特性，其强大的功能令我垂涎已久，并琢磨着为Groovy也添加类似特性，终于在Groovy 4中决定完成这一夙愿。GINQ是Groovy-Integrated Query的缩写，意在对集合的操作以类SQL的方式完成，将来或许会扩展至对数据库的支持。另外，结合Groovy的XML, JSON, YAML等文本解析特性，GINQ可天然地支持对这些文本内容进行查询。

概况

Groovy最初于2003年由James Strachan设计并实现了其原型，迄今已十八岁。Groovy的成长过程，也是众多智者贡献心力的过程。而我大约在2006年底开始研究Groovy，那时Groovy 1.0正式版还没发布，主要由Jochen Theodorou一人维护，所以Jochen Theodorou在我心里一直是Groovy的养父。当初如果没有他的坚持，Groovy很可能早已夭折。而在Groovy 1.0正式版本发布后，Groovy的贡献者逐渐增多，其中令我印象比较深刻的贡献者有以下这么几位：

  虽然Groovy 3 Alpha版本就已经支持Java 8的Lambda、Method Reference以及Constructor Reference全部语法，但从bytecode层面来看，其本质上依然是Closure及Method Pointer，换言之，只是语法上的兼容，但性能上并没有提升。而Groovy的性能常为人诟病，所以Groovy 2引入了静态编译，其编译出来的bytecode跟Java的相近，所以其性能逼近Java。为了延续静态编译的性能优势，Groovy核心团队决定在Groovy 3 Beta版本中实现Lambda、Method Reference以及Constructor Reference的Native版本，其语法不变，但生成的bytecode与Java的相似，这便是”Native”的由来。

问题现象

当select的返回记录类型设置为map(或者其他Map类型，比如java.util.HashMap等)时，返回的map对象可能并未包含所有字段，即只出现有值的字段，而这恰恰是MyBatis的默认处理方式。

背景介绍

Groovy面世已有10多年光阴，在不断创新的同时还汲取了不少其他语言的优秀特性。目前Groovy核心团队已开始将重心逐渐转移到Groovy 3的研发上，而Groovy 3的主要亮点之一便是其全新的解析器以及更加丰富的语言特性。由于前期为Groovy研发了这一全新的解析器并添加了不少语言特性，有幸受邀成为Groovy核心团队的一员。最初我将该全新的解析器命名为“Parrot”，其含义相对比较谦卑，即“鹦鹉学舌”，学着如何说Groovy以及Java8，通过数月陆陆续续地完善，已达到一定的成熟度并已被纳入master分支。