在J2EE 1.3中消除服务定位器实现中的缓存 - 编程入门网
| 身执行所有的 JNDI 代码。下面是我 所得到的两个 toString() 的内容：
那么，上面的内容代表什么呢？类 com.ibm.ws.rsadapter.jdbc.WSJdbcDataSource 是专有的 WebSphere Application Server 类，实现 JDBC 数据源，这个类并不重要。重 要的部分是在末尾的十六进制的数字，他们是实例对象标识符（OID）。 注意到两个 OID 不相同。这就显示两个 bean 使用两个不同的数据源。 我第二个实现使用了缓存服务定位器。JNDI 查找代码在服务定位器实现体内，实现缓 存资源的功能。由于两个 bean 使用相同资源名： jdbc/datasource，所以服务定位器将 缓存第一个查找并将其重用于第二个 bean。下面是输出结果：
注意到两个 OID 是相同的。由于缓存服务定位器的原因，两个 bean 现在使用相同数 据源。第二个 bean 使用第一个 bean 的数据源， 而这恰恰是错误的。 我的第三个实现使用没有缓存的服务定位器。服务定位器代码两次查找资源，因为第 一次查找没有被缓存起来。下面是输出结果：
这里的 OID 是不同的。因为没有缓存，每个 bean 都得到了正确的数据源。正如所预 测的那样，重载的资源名和缓存服务定位器使得代码执行有不同的结果，它使某些组件取 得错误的资源。 修改实现 我们已经看到了重载资源名和典型服务定位器实现，有资源缓存的集合，但他们之间 并没有很好的合作。为何这样呢？更重要的是，我们可以修改它么？ 为何缓存？ 好，既然是由于缓存服务定位器导致重载资源名时的错误。我们为何又非得要缓存呢 ？ 当首次使用 Service Locator 模式开发 J2EE 1.2 应用程序时，因为 JNDI 查找时常 降低甚至有损于执行性能，所以缓存资源引用在当时是一个很好的主意。J2EE 容器提供 商发现了执行性能方面的问题并在 J2EE 1.3 中改进了他们的实现。因此，对于 J2EE 1.3 来说，JNDI 查找执行的非常不错，而此时缓存查找就没有多大用处了。 不要只假设缓存服务定位器能显著的提高应用程序的性能，要使用性能测试来证明这 一点。即使缓存能提高性能，当组件接收它所映射的资源失败时，也是一件痛苦的事情。 “当然，组建取得了错误的资源当然不能正常工作，但是，要感谢缓存，它失败的 却是很快。”，执行迅速但不能正常工作的代码并不是好的。 缓存甚至不是 Service Locator 模式的主要点。Service Locator 的推动是创建简单 、整洁的 API，以一种统一的方式来定位、访问其他服务和组建。缓存只是一种最优化。 它是想要使定位器将相同的功能执行的更快。并不是要改变定位器的行为，结果 必须是 相同的或没有缓存。无疑地，正如本文所展示的，缓存可以改变定位器的返回结果，因此 就改变了应用程序的行为。 所以缓存并不是我们想要的。在正确的行为与快速的行为之间的抉择，正确性每次都 会取得胜利。 为对象缓存的最好的方式是存储任何的它要在实例变量中使用的 JNDI 引用。每个实 例必须初始化其自身的缓存，但它只缓存那些它要使用的引用，并且可以直接访问引用而 不是要到一个散列映射中去寻找。试图努力避免取得重复的相同值总是一个很好的实践， 即使对可以缓存的服务定位器来说也是这样。相反，只取得一次值，然后将其存储在一个 变量中，以一个具有描述性的名称 |
凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢! |
