如何在多个 EJB 之间共享 Java 缓存系统 (JCS) 资源
我使用 JCS 来存储 ldap 搜索结果，该结果应由多个 EJB 共享。我创建了一个单例类来仅初始化 JCS 一次，但由于 EJB 的类加载器，它已使用自己的副本初始化了多次。所以搜索资源不共享。
你们如何解决需要在多个 bean 之间共享缓存的问题？ 我正在寻找 JVM 内的缓存。 （不是远程，例如 memcached 等）。
Glassfish 用作应用程序服务器。
I am using JCS to store the ldap search results which should be shared by multiple EJB. I have created a singleton class to initialize JCS only once but due to EJB's classloader, it's been initialized multiple times with its own copy. so search resources are not shared.
How are you guys resolving issue where you need to share the cache across multiple beans?
I am looking for cache within JVM. (Not the remote e.g memcached etc.).
Glassfish is used as an application server.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我还无法测试它，但我认为 针对您所使用的 Glassfish 版本的应用程序开发指南中的“规避类加载器隔离” 章节可能会解决您的问题。
简短版本，至少对版本 2-3-4 有效：使用通用类加载器（该通用类加载器到底做什么以及它与其他类加载器的关系在同一手册中进行了解释）。有多种方法可以执行此操作：
asadmin add-library --type common /path/to/your.jar（仅适用于版本 4 iirc）这里有几个与“规避类加载器隔离”相关的问题（只需使用该搜索词），在那里寻找示例和更多讨论。
I haven't been able to test it yet, but I think that one of the techniques explained in the "Circumventing Class Loader Isolation" chapter of the Application Development Guide for the version of Glassfish you are using may solve you problem.
Short version, at least valid for versions 2-3-4 : use the Common Classloader (what exactly this common classloader does and its relation to the other classloaders is explained in the same manual). There are several ways to do this:
asadmin add-library --type common /path/to/your.jar(will only work in version 4 iirc)There are several questions here on SO that are related to "Circumventing Class Loader Isolation" (just use that search term), look there for examples and more discussion.
简而言之，单例很可能“存在”在缓存实现类所在的位置，因为这是层次结构中“拥有”该类的类加载器。
因此，如果每个 EJB 是单独部署的，并且具有自己的缓存库 jar 副本，那么它们将各自获得自己的副本。
如果您的 bean 部署在复合 EAR 中，共享 lib jar 的单个实例，则该缓存将在 EAR 中的 bean 之间共享。
如果您从部署中完全删除 lib，并将其放在容器外部（例如 $DOMAIN/lib/ext），那么该缓存将被域中的所有内容（EJB、EAR、WAR 等）共享。
Simply put, the singleton will likely "live" where your caching implementation class lives, as that's the classloader in the hierarchy that "owns" the class.
So, if each EJB is separately deployed, with their own copy of the cache lib jar, they'll each get their own copy.
If your beans are deployed in a composite EAR, sharing a single instance of the lib jar, then that cache will be shared across the beans in the EAR.
If you remove the lib from the deployment completely, and put it outside the container ($DOMAIN/lib/ext for example), then that cache will be shared by EVERYTHING in the domain (EJBs, EARs, WARs, etc.).