geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Blewitt <>
Subject Re: [jndi] To cache, or not to cache
Date Fri, 29 Aug 2003 11:22:00 GMT
On Friday, Aug 29, 2003, at 12:25 Europe/London, Richard Monson-Haefel 

> On 8/29/03 12:36 AM, in article
>, "Alex Blewitt"
> <> wrote:
>> On Friday, Aug 29, 2003, at 08:55 Europe/London, Richard Monson-Haefel
>> wrote:
>>> 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.
> Well, not really.  Each deployment's ENC is static, so if you deploy a 
> bean,
> the container simply creates its ENC at that moment, but once its 
> created
> its static. It cannot be changed by the bean nor can any values be 
> modified,
> bound or unbound.

Actually, that is not the case ...

>> 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.
> That's just the way it is. J2EE specifies that the JNDI ENC is 
> read-only. If
> you want to access a non-static JNDI resource, you must connect to it
> explicitly.

Not directly true ...

>> Of course caching is always likely to provide better performance in 
>> any
>> case, but it still does not have to be static.
> If you want it to be conformant it does.

What the J2EE spec says (J2EE 5.2.4):

"The container must ensure that the application component instances 
have only
read access to their environment variables. The container must throw the
javax.naming.OperationNotSupportedException from all the methods of the
javax.naming.Context interface that modify the environment naming 
and its subcontexts."

What this means is the /client's/ view is unmodifiable -- it does not 
say that the JNDI namespace/back-end is unmodifiable. Indeed, the 
AppServer /needs/ to be able to write into the JNDI spec during startup 
(or indeed, during subsequent deployments.

In essence, the JNDI /must/ be read-write, but the client view /must/ 
be read-only.

> Don't get me wrong. I think we need LDAP functionality and I would like
> nothing better than to see LDAPd used in Geronimo, I just don't think 
> its a
> proper fit for the JNDI ENC unless it provides the kind of caching 
> that I
> discussed earlier.

No reason why the client proxy can't do caching on the fly as well. I 
imgaine the client view would be similar to a 
Collections.unmodifiableCollection() wrapper, and as well as doing 

public class ClientContext extends Context {
   private Map cache = new HashMap();
   public ClientContext(Context context) {
   public Object lookup(String name) {
     Object result = cache.get(name);
     if (result == null) {
       result = context.lookup(name);
     return result;
   public void bind(Object o, String name) {
     throw new OperationNotSupportedException();
   // etc

[With extra methods/exceptions/etc :-)]


View raw message