先华为后天
#1
如题，并发控制概述这章节的内容好乱，里面各种名词，还有接近的，也没相应的术语表、和其用途描述。下面是这章节提到的名词，下面这些相近的名词如果是同一个内容是不是可以统一下：
【 读版本号和提交版本号、本地最大读时间戳、最大提交时间戳、本地提交版本号、全局提交版本号、全局提交时间戳、最大读事务时间戳、最大提交事务时间戳、本地提交版本、全局提交版本、本地时间戳、本地提交时间戳、全局时间缓存服务】
整个ob的文档看着感觉都比较乱。
这里的全局时间戳缓存服务由谁提供？内容是什么？
对于这种提供全局授时的分布式式服务其实就是事务开始时间，比对比开始时间小的就可读，提交时获取提交时间就可以了，为什么ob上的描述这么复杂，一会本地一会全局一会最大的，引入本地版本或时间的目的是什么？
https://open.oceanbase.com/docs/observer-cn/V3.1.2/10000000000016183
- 您好, 不好意思给您带来了不好的体验. 我们之后会想办法优化一下这部分术语, 并统一在抬头描述一下逻辑.
- 这里的全局时间戳缓存服务由谁提供？内容是什么？ 全局时间戳缓存服务是由 https://www.oceanbase.com/docs/oceanbase-database/oceanbase-database/V3.2.2/global-timestamp 这一章节做的一个缓存服务, 在合理的情况下复用时间戳(部分参与者的本地提交版本号就是从此服务获取), 这一部分并没有细节描述, 我们之后会加以详细解释
- 对于这种提供全局授时的分布式式服务其实就是事务开始时间，比对比开始时间小的就可读，提交时获取提交时间就可以了，为什么ob上的描述这么复杂，一会本地一会全局一会最大的，引入本地版本或时间的目的是什么？因为如果直接使用全局授时的分布式式服务的话在读写并发控制下表现不是那么好, 比如说一个事务 T1 开始时间戳是1, 在没有提交以前, 对于读时间戳为 3 事务 T2, 没有办法能够确认是否能读, 因为事务 T1, 最后可能以 2 或 4 作为时间戳来提交. 因此我们引入了本地提交时间戳来做优化. 本地提交时间戳只有事务进入提交阶段才会获取, 其值大于所有产生过读取的事务的读时间戳. 因此对于前一场景, 只要事务 T2 读取时事务 T1 没有进入提交阶段, T2 就可以确认可以读取. 而事务 T1 提交时就会通过全局时间戳缓存服务所记住的 T2 的读时间戳2, 而保证事务 T1 提交时间戳大于 2. 最终保证正确的并发控制
最后感谢您的提问, 我们会努力改进这一块, 给您带来更好的体验
先华为后天
#3
对于第二点，时间戳应该是连续递增的吧，事务T1开始时1，T2获取的时间戳已经是3了，那T1在T2开始时还没完成提交的情况下，GTS不会给分配低于3的时间戳吧，还是说有其他特殊或例外情况
