应用与DLL共享FireDAC连接时的事务处理风险及原因咨询

我来给你详细拆解一下Embarcadero这段官方说明，以及违规操作会带来的具体坑点：

一、官方说明的核心逻辑 #

FireDAC的连接对象由主程序创建和管理，但主程序的FireDAC框架不会跟踪DLL模块内对连接状态的任何变更——这是因为主程序和DLL是两个独立的执行模块，FireDAC的事务管理、连接配置逻辑绑定在主程序的上下文里，DLL里的操作相当于“偷偷”修改了连接状态，但主程序完全不知情。

基于这个前提，官方给出的禁止操作背后的原因是：

• 必须保持调用前的事务状态：主程序调用DLL时，可能已经处于某个事务流程中（比如开启了未提交的事务），如果DLL随意提交、回滚或者开启新事务，会直接打破主程序的事务预期，让后续操作陷入错误状态。
• 不建议在DLL中处理事务：事务需要明确的边界，主程序和DLL的事务上下文不共享，两边都无法感知对方的事务操作，很容易出现事务拆分、遗漏的情况。
• 禁止更改事务隔离级别及其他设置：这些配置绑定在连接实例上，DLL修改后，主程序后续使用该连接的所有操作都会沿用这个被修改的配置，完全破坏主程序原本的业务逻辑设计。

二、在DLL中处理事务的具体后果 #

如果无视官方建议，在DLL里处理事务，会遇到一系列难以排查的问题：

• 事务边界混乱，数据一致性被破坏：比如主程序开启了一个全局事务，调用DLL处理部分数据，结果DLL私自提交了事务，主程序后续操作失败需要回滚时，已经提交的DLL部分数据无法回滚，最终导致数据部分生效、部分回滚，完全不符合原子性要求。
• 连接状态被污染，主程序逻辑异常：如果DLL修改了事务隔离级别（比如从默认的读已提交改成可重复读），主程序后续用同一个连接执行查询时，会出现锁竞争加剧、查询结果不符合预期的情况，而且你很难定位到问题根源——因为主程序本身根本没修改过隔离级别。
• 未提交事务导致资源泄漏：如果DLL开启事务后因为崩溃、异常等原因没提交/回滚，主程序又不知道这个事务的存在，数据库会一直持有这个事务的资源，不仅会占用连接池资源，还可能导致锁表、事务日志暴涨，拖慢整个数据库的性能。
• 跨模块事务协调失败：如果主程序和DLL同时操作同一个连接的事务，两边的提交、回滚操作会互相干扰，比如主程序准备回滚时，DLL已经提交了，或者反过来，导致整个事务逻辑彻底混乱，出现莫名其妙的提交/回滚结果。

内容的提问来源于stack exchange，提问作者Samuel