geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Strachan <james_strac...@yahoo.co.uk>
Subject Re: [jndi] To cache, or not to cache
Date Fri, 29 Aug 2003 12:16:17 GMT
Alex, are you confusing a particular deployments' JNDI ENC (e.g. for an 
ejb ear or war) from JNDI in general? They're very different things.


On Friday, August 29, 2003, at 12:22  pm, Alex Blewitt wrote:

> On Friday, Aug 29, 2003, at 12:25 Europe/London, Richard Monson-Haefel 
> wrote:
>
>> On 8/29/03 12:36 AM, in article
>> 812C0D21-D9F3-11D7-9E84-0003934D3EA4@ioshq.com, "Alex Blewitt"
>> <Alex.Blewitt@ioshq.com> 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 
> context
> 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 
> caching:
>
> 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);
>       map.put(name,result);
>     }
>     return result;
>   }
>   public void bind(Object o, String name) {
>     throw new OperationNotSupportedException();
>   }
>   // etc
> }
>
> [With extra methods/exceptions/etc :-)]
>
> Alex.
>

James
-------
http://radio.weblogs.com/0112098/


Mime
View raw message