我正在开发一个简单的 Java EE 5“路由”应用程序。来自一个MQ队列的不同消息先进行转换，然后根据某个字段的值，存储到不同的数据源中（需要调用不同ds中的存储过程）。
例如 valueX -> dataSource1，valueY -> dataSource2。所有数据源都使用不同的 jndi 条目在应用程序服务器中设置。由于应用程序运行时路由信息通常不会改变，是否保存缓存数据源查找？例如，我将实现一个单例，它包含一个哈希图，我在其中存储 valueX->DataSource1。当某个条目不在列表中时，我会进行资源查找并将结果存储在地图中。我是否可以通过缓存获得任何性能，或者这些资源查找是否足够快？
一般来说，构建这种缓存的最佳方法是什么？我也可以将缓存用于其他一些数据库查找。例如，映射 valueX -> 资源名称在 DB 中的一个简单表中定义。按需查找值并将结果保存在地图中，始终进行查找，甚至在启动时读取并保存所有条目是否更好？我需要同步访问吗？我可以只创建一个“枚举”单例实现吗？
从操作/变更管理的角度来看，它是安全的，但从程序员的角度来看是不安全的。
从程序员的 PoV 来看，DataSource 配置可以在运行时更改，因此应该始终重复查找。
但这不是现实生活中发生的事情。
当要实现对数据源的更改时，这是通过更改管理过程完成的。有 ac/r 记录，该记录表明应用程序将停机。换句话说，执行 c/r 的操作人员将关闭应用程序，进行更改并将其恢复。出于安全原因，没有人在实时 AS 上进行这样的更改。因此，您不应考虑 DS 在运行时更改的可能性。
所以任何永久同步的共享缓存在这种情况下都是好的。
你会得到性能提升吗？这取决于 AS 实现。它可能有自己的缓存，但该缓存可能更通用且速度更慢，实际上您根本无法指望它的存在。
你需要建立一个缓存吗？答案通常来自性能测试。如果没有问题，为什么要浪费时间和引入风险？
简历：是的，构建一个简单的缓存并使用它——如果性能提升证明它是合理的。
具体实施取决于您的偏好。我通常有一个按需查找的缓存，并且里面有一个 jndi->object 的同步映射。对于高并发缓存，我会使用读/写锁而不是简单的同步——即许多读取可以并行进行，而添加新条目将获得独占访问。但这些细节很大程度上取决于应用程序的详细信息。