使用seata作为分布式事务协调框架，有几个问题想请各位专家确认下。

3. seata全局事务"读已提交"隔离级别"通过全局锁实现，我比较疑惑，这需要阻止新的分支事务读写实际已提交到数据库的数据，等于seata内部要为那些已提交的行记录添加排他锁，那么请问这些排他锁是利用数据库自身的锁还是seata实现的呢？

1. 正在执行跨服务事务时，未提交的分支事务所在服务重启，是否仍能保证数据一致性？如果分支事务超时失败，那么全局事务回滚，虽然全局事务失败了，但数据一致性似乎可以得到保障(假设没有发生seata全局事务层面的"脏写")？

2. seata通过全局锁提供的全局事务隔离级别是建立在数据库隔离级别基础上，mysql数据库默认隔离级别为可重复读，那么使用seata+mysql时分支事务的默认隔离级别就是可重复读？spring集成seata的@Transactional注解是否同样支持level设定分支事务隔离级别？

3. seata全局事务"读已提交"隔离级别"通过全局锁实现，我比较疑惑，这需要阻止新的分支事务读写实际已提交到数据库的数据，等于seata内部要为那些已提交的行记录添加排他锁，那么请问这些排他锁是利用数据库自身的锁还是seata实现的呢？

我正在评估在工作中使用seata来解决分布式事务协调问题，对于使用seata作为分布式事务协调框架，有几个问题想请各位专家确认下。

1. 正在执行跨服务事务时，未提交的分支事务所在服务重启，是否仍能保证数据一致性？如果分支事务超时失败，那么全局事务回滚，虽然全局事务失败了，但数据一致性似乎可以得到保障(假设没有发生seata全局事务层面的"脏写")？

2. seata通过全局锁提供的全局事务隔离级别是建立在数据库隔离级别基础上，mysql数据库默认隔离级别为可重复读，那么使用seata+mysql时分支事务的默认隔离级别就是可重复读？spring集成seata的@Transactional注解是否同样支持level设定分支事务隔离级别？

3. seata全局事务"读已提交"隔离级别"通过全局锁实现，我比较疑惑，这需要阻止新的分支事务读写实际已提交到数据库的数据，等于seata内部要为那些已提交的行记录添加排他锁，那么请问这些排他锁是利用数据库自身的锁还是seata实现的呢？

4. 假如全局事务回滚中发现脏写？需要人工介入，请问seata是否支持告警通知。