Mailing-List: contact geronimo-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: geronimo-dev@incubator.apache.org
Date: Sun, 31 Aug 2003 12:25:07 -0500
Subject: Re: [jndi] Have we found a JNDI impl yet?
Content-Type: text/plain; charset=WINDOWS-1252; format=flowed
Mime-Version: 1.0 (Apple Message framework v552)
From: Dain Sundstrom <dain@coredevelopers.net>
To: geronimo-dev@incubator.apache.org
Content-Transfer-Encoding: quoted-printable
In-Reply-To: <2A3A89F1-DBA8-11D7-8B65-0003934D3EA4@ioshq.com>
Message-Id: <11454746-DBD8-11D7-A2AE-000393DB559A@coredevelopers.net>

\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=20
>>> therefore a very simple, and fast, in-memeory caching strategy works=20=

>>> best.
>> Yes, as far as the ejb deployment unit is concerned, it's java ENC is=20=

>> 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=20=

> mutable at some level.

Alex go read the code.  What we have right now is an immutable context=20=

that you bind into you existing JNDI implementation... so we have a=20
node that can be put into *any* tree.  The base tree must be mutable so=20=

we can bind our context, and after that every thing below us in the=20
tree will be read only.

>>> Will your impl support this type of caching?  In OpenEJB, the JNDI=20=

>>> ENC impl caches lookups in a HashMap so that subsequent lookups=20
>>> using the same JNDI name are wicked fast =96 fast as a Hashtable=20
>>> lookup on a small data set.  I know that we can use the advanced=20
>>> features of LDAPd in many areas of Geronimo (security,=20
>>> configuration, etc.) but for the JNDI ENC, I think it would be best=20=

>>> if we used something lighter.  Perhaps, you can provide a caching=20
>>> impl for static data sets like this?  The thing is, in most=20
>>> deployments, the number of items stored in the JNDI ENC for a=20
>>> particular component is very small. Speed is of the essence =96 you=20=

>>> can=92t get much faster than a HashMap. ;-)
>>
>> Just to lend further weight to the in-memory vs external storage=20
>> java:comp/env namespace, the experience over at JBoss was that stress=20=

>> testing showed up that just thread sychronisation on the context=20
>> environment Properties used by NamingParsers was a significant=20
>> performance bottleneck. Therefore the throughput could only get worse=20=

>> 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=20
> external process, but this is an example of way-too-early=20
> optimisation. How many times does the JNDI server get consulted?=20
> Probably only when the application starts up -- most apps cache=20
> Home/DataSource instances anyway, so the speed of lookup is in no way=20=

> 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=20=

> in the bottleneck and (b) that X has a clear advantage over Y. For=20
> example, it may be that the execution speed of lookup is actually=20
> unimportant whereas the amount of memory committed to cache is very=20
> important. And given that apps will cache values from JNDI (most of=20
> the time) then the cache will become essentially a dual-copy of the=20
> memory.
>
> Let's look at lots of ideas, and avoid 'because it is slower'=20
> 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=20
are places we know are not important.  We know this because most of the=20=

committers have written a J2EE server before.  In this case we know=20
people do make lots of JNDI look ups, and yes they should cache it but=20=

they don't.

Anyway the important feature is not the speed.  The important feature=20
is that it is read only, which is required by the spec.  Read the code=20=

and you will see that our context is simple (although I can think of a=20=

few ways to make it easier to construct).

-dain