SQL Server中仅查询执行期间动态调整事务隔离级别的方案咨询

以下方案按改造成本从低到高排序，均可以满足单查询动态调整隔离级别的需求：

方案1：自定义SQLServer DBDictionary（推荐，原有业务代码零改造） #

官方默认的SQLServerDictionary未实现单查询隔离级别适配，因此抛出不支持的报错，可通过扩展该类的方式复用原有hint逻辑：

• 实现步骤：
  1. 新建自定义类继承org.apache.openjpa.jdbc.sql.SQLServerDictionary
  2. 重写supportsIsolationLevelForSelect()方法，直接返回true
  3. 重写addSelectIsolationLevelSQL方法，当传入的隔离级别为READ_UNCOMMITTED时，为查询涉及的所有表自动拼接WITH (NOLOCK)表提示
  4. 修改OpenJPA配置，将openjpa.jdbc.DBDictionary参数的值替换为自定义类的全限定类名
• 优势：原有query.setHint("openjpa.FetchPlan.Isolation", "READ_UNCOMMITTED")的代码完全不需要改动，适配成本极低，且直接使用表提示无需调整连接的全局隔离级别，不存在隔离级别泄漏影响其他业务的风险

方案2：连接层扩展实现隔离级别自动设置与重置 #

如果需要严格使用SET TRANSACTION ISOLATION LEVEL的逻辑而非表提示，可通过OpenJPA和连接池的扩展点避免隔离级别泄漏：

• 实现步骤：
  1. 实现OpenJPA的ConnectionCustomizer接口，在连接被获取的回调方法中检测当前请求上下文的FetchPlan配置的隔离级别，若为READ_UNCOMMITTED则执行语句SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED
  2. 配置主流连接池（HikariCP、DBCP2均原生支持）的连接归还监听钩子，强制执行SET TRANSACTION ISOLATION LEVEL READ COMMITTED将隔离级别重置为默认值
• 优势：完全匹配原有DB2的隔离级别调整逻辑，无需修改查询层代码
• 注意：需确保连接归还的重置逻辑在异常场景下也能正常触发，避免隔离级别泄漏

方案3：查询层显式配置NOLOCK提示 #

如果不想扩展OpenJPA内核，可针对需要READ_UNCOMMITTED的查询单独加提示：

• 实现方式：给对应查询增加hint配置：query.setHint("openjpa.hint.SQLServer.TableHint", "WITH (NOLOCK)")，如果是注解形式的命名查询，可在@QueryHint中配置对应参数，OpenJPA生成SQL时会自动为查询表增加NOLOCK提示
• 优势：逻辑简单无内核扩展风险
• 劣势：需要逐个修改需要调整隔离级别的查询代码，改造成本随涉及的查询数量增加而上升

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