geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Blewitt <>
Subject Re: [jndi] Have we found a JNDI impl yet?
Date Sun, 31 Aug 2003 11:42:14 GMT
On Sunday, Aug 31, 2003, at 04:42 Europe/London, Jan Bartel wrote:

> Richard Monson-Haefel wrote:
>> The JNDI ENC is totally static at runtime (per deployment) and 
>> therefore a very simple, and fast, in-memeory caching strategy works 
>> best.
> Yes, as far as the ejb deployment unit is concerned, it's java ENC is 
> immutable (although this might be mutable by, eg, the ejb container).

I know, but to have a mutable and immutable view then the JNDI must be 
mutable at some level.

>> Will your impl support this type of caching?  In OpenEJB, the JNDI 
>> ENC impl caches lookups in a HashMap so that subsequent lookups using 
>> the same JNDI name are wicked fast – fast as a Hashtable lookup on a 
>> small data set.  I know that we can use the advanced features of 
>> LDAPd in many areas of Geronimo (security, configuration, etc.) but 
>> for the JNDI ENC, I think it would be best if we used something 
>> lighter.  Perhaps, you can provide a caching impl for static data 
>> sets like this?  The thing is, in most deployments, the number of 
>> items stored in the JNDI ENC for a particular component is very 
>> small. Speed is of the essence – you can’t get much faster than a 
>> HashMap. ;-)
> Just to lend further weight to the in-memory vs external storage 
> java:comp/env namespace, the experience over at JBoss was that stress 
> testing showed up that just thread sychronisation on the context 
> environment Properties used by NamingParsers was a significant 
> performance bottleneck. Therefore the throughput could only get worse 
> if we added an external storage mechansism to the lookup process.

I can imagine that an in-memory cache is going to be faster than an 
external process, but this is an example of way-too-early optimisation. 
How many times does the JNDI server get consulted? Probably only when 
the application starts up -- most apps cache Home/DataSource instances 
anyway, so the speed of lookup is in no way going to be a bottleneck to 
the runtime part of the system.

There's no point in optimising unless it can be shown that (a) it is in 
the bottleneck and (b) that X has a clear advantage over Y. For 
example, it may be that the execution speed of lookup is actually 
unimportant whereas the amount of memory committed to cache is very 
important. And given that apps will cache values from JNDI (most of the 
time) then the cache will become essentially a dual-copy of the memory.

Let's look at lots of ideas, and avoid 'because it is slower' arguments 
until we can actually show that this is the case.


View raw message