ob的热点行更新能力在分布式事务2pc的什么阶段释放锁资源？ELR功能是默认开启的吗？
4.1和4.2版本，ELR是默认打开的。2pc过程中，参与者收到协调者发送的pre-commit请求后，推高本地版本号，就可以解开行锁了，不用等到commit阶段。
解开行锁后，如果释放锁的事务的全局提交时间戳大于在该事务释放锁后获得锁的事务的读时间戳，这时候还会回滚后面这个事务吗？
对于读操作会有什么影响吗？是让事务可以读已经释放锁的事务，还是说当事务读到prepare阶段的事务等待最终提交时间戳的确定后在进行读取或者跳过？
提前解锁的目的，就是为了当前事务更新的数据能够更早地被其他事务读到，提前解行锁不影响版本号机制，只是更早地解锁。如果事务最终成功提交，那么后续的事务都可以正常执行；如果事务最终失败，那么依赖它的其他事务也会跟着回滚。
对于读操作，能够更快读到前一个写操作更新后的数据，但需要等前一个事务确认提交之后再将查询结果返回，最终是要满足“读已提交”隔离级别的。
如果是为了满足ob的快照读隔离级别的话，elr是开启的还是关闭的
ELR不影响隔离级别，对用户而言是透明的。
那在不改变版本号机制的情况下，为了事务的更新更早的被其他事务读到，在推高本地版本号后。如果读时间戳大于本地提交时间戳，让其读取后，事务提交，最终提交时间戳大于读操作的时间戳，此时读事务再一次读取此行，会根据读请求处理，跳过该数据，这样不就出错了吗？达不到快照读的级别。
如果是读到prepare阶段的等待事务提交，那么事务提前解行锁和事务读取也就没有关系了
“如果读时间戳大于本地提交时间戳，让其读取后”不太对，读时间戳要大于事务提交时间戳，才能读到前面事务修改的数据。提前解锁并不违背这一原则。所谓“提前”，是指参与者还没有持久化commit log时就释放行锁，存在事务回滚的可能性。