All this sounds great, Alex, but I’m a little concerned that its overkill for the JNDI ENC. The JNDI ENC is totally static at runtime (per deployment) and therefore a very simple, and fast, in-memeory caching strategy works best.
Is this necessarily the case? It has to be able to start up EJBs and write into the JNDI ENC during runtime; if it is going to support on-the-fly deployment of other EJBs, I'd say that it must be able to handle additional extras inserted in at runtime.
I also don't see why code cannot necessarily register additional things in the JNDI ENC, such as other databases populated by an initialisation code. I know that it's not likely that this will be the case, but assuming that it is totally static seems a wrong decision.
Of course caching is always likely to provide better performance in any case, but it still does not have to be static.
Alex (B).
