1, server abstraction into a service, but brought the consumption of rpc, why give up embedded in the application? // 1、server抽象成服务,但是带来了rpc的消耗,为什么放弃 嵌入在应用呢? Can you tell the pros and cons of the selection? // 能否告知选型的利弊?
2, on the beforImage and afterImage, the framework in the implementation of the actual implementation of the update, select for update [previously according to the update conditions, the next time according to the primary key]. This should be strictly required in the sql generated for the business. Otherwise it is easy to bring the problem of deadlock. I hope that the later documents will be more abundant. // 2、关于beforImage和afterImage,框架 在执行真正执行update时,先后都 select for update【前一次根据更新条件,后一次根据主键】。 这样在对业务生成的sql上面应该是需要有严格的要求的吧。否则很容易带来死锁的问题吧。希望后期文档能更丰富一点
// 3, now open source is AT mode, MT mode is temporarily not supported, when will open source? // 3、现在开源的是AT模式,MT模式暂时不支持,啥时候会开源呀?
//
原提问者GitHub用户xuyang0902
就我读源码来看: branch断电后,tc会把回滚的branch放到队列中,branch alive后就可以回滚到之前的数据快照了。且在这段时间内,如果有人想通过fescar修改这个branch涉及到的数据 是不被允许的(fescar有一个全局锁)。 关于锁和隔离性 这是一个很有趣的话题。
原回答者GitHub用户xuyang0902
版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。
阿里云拥有国内全面的云原生产品技术以及大规模的云原生应用实践,通过全面容器化、核心技术互联网化、应用 Serverless 化三大范式,助力制造业企业高效上云,实现系统稳定、应用敏捷智能。拥抱云原生,让创新无处不在。