服务器定义的JNDI MailSession对比运行时创建的优劣探讨

我在Glassfish服务器管理面板中为每个客户端（域名）配置了多个MailSession，通过JNDI资源注入。为简化示例，此处采用硬编码方式，代码如下：

// mail session for domain "foo.com"
@Resource(name = "mail/fooCom")
private Session mailSessionFooCom;


// mail session for domain "bar.com"
@Resource(name = "mail/barCom")
private Session mailSessionBarCom;

根据要发送邮件的客户端选择对应的Session实例。这种方式配置灵活性不足，新增客户端时需在Glassfish管理控制台添加新邮件会话并重启服务器。考虑改为将每个客户端的邮件属性存储在数据库中，发送邮件时在运行时创建Session实例。现咨询：运行时创建Session有哪些弊端？JNDI绑定的MailSession具备哪些优势？

• 资源复用性差：每次发送邮件都新建Session实例，无法利用Glassfish内置的连接池机制，频繁创建销毁会显著增加系统资源开销，高并发场景下性能损耗尤为明显。
• 缺失容器级管控能力：无法借助Glassfish的监控、日志、故障自愈机制。比如容器会自动处理邮件服务器连接异常的重试、闲置资源回收，运行时创建的Session需要自行实现这些逻辑，大幅增加代码复杂度。
• 配置校验滞后：数据库中存储的邮件属性（如SMTP地址、认证信息）如果有误，只有在触发邮件发送时才会暴露问题，无法在容器启动阶段提前校验配置合法性。
• 安全风险更高：邮件账号密码等敏感信息存放在数据库中，需额外实现加密、权限控制逻辑；而JNDI绑定的MailSession可依托Glassfish的加密存储能力，天然保护敏感配置。
• 代码冗余繁琐：需要手动编写Session初始化、属性加载、认证配置等重复逻辑，代码复杂度提升，也更容易引入人为bug。

• 容器托管的资源池化：Glassfish会对MailSession进行池化管理，复用连接与Session实例，大幅降低资源消耗，在高并发邮件发送场景下性能优势显著。
• 集中化配置管理：所有邮件会话配置统一在Glassfish管理面板维护，无需修改业务代码，配置变更可集中管控，且容器会在启动阶段自动校验配置合法性，提前发现问题。
• 容器级安全保障：SMTP密码等敏感信息可通过Glassfish的加密功能存储，无需在代码或数据库中明文存放，有效降低信息泄露风险。
• 代码实现更简洁：通过@Resource注解直接注入Session，无需手动编写初始化逻辑，代码更简洁，维护成本更低。
• 集成容器监控诊断：Glassfish会对MailSession的使用情况（如连接数、活跃会话数）进行监控，便于排查性能问题；邮件发送故障时，容器日志会提供更清晰的报错上下文，加速问题定位。

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