geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <d...@coredevelopers.net>
Subject Re: [jndi] Have we found a JNDI impl yet?
Date Sun, 31 Aug 2003 17:25:07 GMT
\On Sunday, August 31, 2003, at 06:42 AM, Alex Blewitt wrote:

> 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.

Alex go read the code.  What we have right now is an immutable context 
that you bind into you existing JNDI implementation... so we have a 
node that can be put into *any* tree.  The base tree must be mutable so 
we can bind our context, and after that every thing below us in the 
tree will be read only.

>>> 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.

Alex there are places that we know are critical to be fast and there 
are places we know are not important.  We know this because most of the 
committers have written a J2EE server before.  In this case we know 
people do make lots of JNDI look ups, and yes they should cache it but 
they don't.

Anyway the important feature is not the speed.  The important feature 
is that it is read only, which is required by the spec.  Read the code 
and you will see that our context is simple (although I can think of a 
few ways to make it easier to construct).

-dain



Mime
View raw message