In the ancient :-) J2EE world, there existed some Service Locator implementations, which were able to cache the InitialContext, as well the Home-Stubs internally. The caching of the InitialContext instance was dependend on the application server vendor. Some vendors required to close the InitialContext after every lookup, most of the applications servers like WLS 6,7,8 or JBoss (I didn't used glassfish for J2EE 1.4 development :-)) didn't have problems with "cached" InitialContext. Caching of EJB-Homes was also vendor, and even configuration dependent. It was important to know, whether the Home-Stubs (smart stubs) do refresh the cluster view periodically, or only at the lookup time. In the latter case it wouldn't be a good idea to cache them inside the Service Locator.
In the Java EE 5 world the home interfaces are gone or are at least optional. The Service Locator returns already the Business Interfaces in that case. It is not a good idea to cache business interfaces of stateful session beans... Because it is not possible to determine whether a given interface is stateful or not without knowing the implementation - business interfaces aren't cached at all.
As some of you noticed (thank you Paris), the Java EE 5 implementation of the Service Locator in (Patterns For Java EE 5) neither caches the InitialContext, nor the Business Interfaces. This implementation can be of course optimized, but the initial version is portable.
We will of of course discuss this issue next week in hamburg :-).
Web Apps, SPA, PWA with vanilla Java Script (ES 6+), CSS 3 and WebStandards only. As simple as possible, but not simpler. See you at: (Progressive) Web apps, Single Page Apps and WebStandards airhacks workshops at MUC airport, Winter Edition
airhacks.fm the podcast:
Stay in touch: airhacks.news.