Hibernate与存储过程关联及连接池下临时表已存在异常解决策略

问题根因 #

这个异常的触发逻辑非常明确：会话级临时表的生命周期和数据库物理连接完全绑定，而连接池的设计是复用物理连接，事务结束后连接只会被回收归池，不会真的关闭，上一次连接使用时创建的临时表会一直存在，下次复用这个连接再建同名临时表就会报错。

可落地的解决方案 #

根据不同的业务场景，你可以选最适合的方案：

• 前置删除兜底，改造成本几乎为0
  建表之前先执行删表判断语句，比如MySQL就写 DROP TEMPORARY TABLE IF EXISTS temp_table_name;，Oracle可以先查user_temporary_tables数据字典判断表存在就删除，或者直接捕获建表异常，删表后重试创建。如果你的临时表命名固定，选这个方案最省事。
• 连接池层统一清理，完全不侵入业务
  主流连接池（HikariCP、Druid、C3P0）都支持配置连接归还到池前的自定义执行逻辑，你可以在回收钩子中统一清理当前连接的临时表，或者直接执行数据库提供的会话重置命令，比如MySQL的RESET SESSION、Oracle的ALTER SESSION CLEAR ALL，直接清空上一次连接使用的所有残留对象，上层业务代码不需要做任何修改。
• 改用事务级临时表，从根源避免冲突
  要是你的临时表仅在当前事务内使用，直接替换为事务级临时表即可，这类临时表会在事务提交/回滚后自动删除，完全不需要处理连接复用的问题，适配成本最低，使用前确认你所使用的数据库版本支持该特性即可。
• 临时表名动态化，适配跨事务使用场景
  如果你需要跨事务复用同一会话的临时表，可以在创建临时表时给表名添加唯一标识，比如拼接当前业务请求ID、事务ID、线程唯一序列号，从命名上避免冲突，临时表使用完成后主动执行删除逻辑即可。
• 独立Session生命周期控制，强隔离场景适用
  要是对临时表的隔离性要求极高，可以在需要使用临时表的逻辑执行前，主动打开独立的Hibernate Session，业务逻辑执行完成后立即关闭Session，强制触发连接回收或物理释放，避免连接被其他逻辑复用时出现残留。

内容的提问来源于stack exchange，提问作者Gurkan İlleez