WebSphere数据源配置验证：修改后仍取PROD数据的排查方法

一、验证数据源修改是否正确的实操方法 #

• 抓包排查实际连接：用Wireshark或tcpdump抓取QA应用服务器的数据库连接请求，直接检查目标IP/主机名是否为QA环境数据库地址，确认实际连接的数据源。
• 核对数据库访问日志：分别查看QA和PROD数据库的访问日志，搜索应用服务器的IP，定位哪些请求落到了PROD，再对应到具体查询语句反推关联的数据源。
• 临时添加日志输出：在代码里加临时日志，打印执行查询时使用的数据源连接信息（如URL、主机名），运行有问题的查询后查看日志，明确实际调用的数据源。
• 重启应用服务：部分框架会缓存数据源连接池，修改配置后未重启可能导致旧连接仍指向PROD，重启后再测试查询是否正常。
• 分数据源单独测试：给每个数据源单独执行简单查询（比如SELECT 1），检查返回的数据库标识（比如PROD特有的库名或测试数据），逐一确认每个数据源的实际指向。

二、数据源配置不止需要检查resources.xml #

• 环境专属配置文件：很多项目会按环境拆分配置，比如application-qa.properties、qa-config.xml这类文件，可能单独配置了数据源信息，需要排查。
• 连接池独立配置：如果用了Druid、HikariCP等连接池，它们可能有独立的配置文件（如druid.properties），里面也会存储数据源地址，别漏查。
• 代码硬编码情况：部分老旧项目可能在DAO层或数据源初始化代码里直接硬编码了PROD地址，没走配置文件，需要排查相关代码。
• 容器级配置：如果应用部署在Tomcat、JBoss等容器中，容器本身的context.xml或后台配置页面可能也配置了数据源，优先级可能高于项目内的resources.xml。
• 远程配置中心：如果用了Nacos、Config Server等配置中心，数据源配置可能存在远程中心，本地resources.xml的配置被远程覆盖，需要检查配置中心的QA环境配置。

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