geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Bartel <>
Subject Re: [jndi] Have we found a JNDI impl yet?
Date Sun, 31 Aug 2003 03:42:33 GMT
Richard Monson-Haefel wrote:
> All this sounds great, Alex, but I’m a little concerned that its 
> overkill for the JNDI ENC.  
Totally agree.

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

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


> On 8/28/03 7:40 AM, in article 
> 000001c36d72$472df780$, "Alex Karasulu" 
> <> wrote:
>     The current architecture has a primitive server side LDAP JNDI provider
>     which is about 70-80% functional.  The provider directly accesses
>     entries
>     within the backend apparatus within the server.  When contexts are
>     initialized they represent an instance/point of access (hence a context)
>     into the directory information tree of the server bypassing the LDAP
>     protocol stack.
>     In the new architecture, to be completed by mid October, the JNDI
>     provider
>     is at the core of the server's backend apparatus and shall be
>     completed by
>     then.  The server side JNDI LDAP provider will wrap something we call a
>     nexus that attaches several databases each with a suffix in the
>     namespace to
>     a central point in the server.  The nexus performs name based
>     routing to the
>     backend that has jurisdiction over the region of the namespace
>     specified by
>     its suffix.  Anyway this apparatus is wrapped by JNDI.  The JNDI
>     becomes the
>     only way to enter the nexus and hence a target backend in the new
>     architecture.  The JNDI is thus a shell around the backend subsystem
>     of the
>     server.  All orthogonal services implemented as Interceptors enable
>     things
>     like triggers, and change notification between calls made by the JNDI
>     provider on the nexus.  This is how we introduce new services into JNDI
>     calls on our provider.
>     There are two ways I can immediately conceive of in which this code
>     can be
>     leveraged to enable a persistant java:comp/env namespace for
>     Geronimo.  But
>     first consider this.  There may be areas where Geronimo will need to
>     access
>     and search over persistent data without having to bring this information
>     into memory - this requires the industrial power of database indexing.
>     Geronimo's configuration is a perfect candidate for storage in the
>     directory
>     - it will most likely be hierarchical in nature and very fitting.
>      Another
>     excellent possibility is the use of the embedded server as the
>     foundation
>     for a security subsystem.  With that in mind lets just look at the
>     way in
>     which we can just enable the java:comp/env namespace while using
>     LDAPd code.
>     First you can build over the LDAP namespace using it as a hierarchical
>     relational database to manage environment data.  A java:comp/env
>     namespace
>     could be implemented using another JNDI provider to wrap the LDAP
>     provider
>     which has the super set of JNDI functionality (Context, DirContext, and
>     LdapContext).  The wrapper provider would simply transform
>     operations into
>     the LDAP namespace according to the designed DIT structure and the
>     schema
>     used for java:comp/env objects.  The neat thing is you would have
>     the power
>     of search to find anything you needed very rapidly.  Much faster than a
>     non-indexed solution - you're getting the power of a database at your
>     disposal this way.  If you go this route then other aspects like
>     configurations can also be stored in different areas of the directory
>     information tree.  Also LDAP replication can be used to replicate your
>     environment and configuration information for clustering in the
>     future.  I
>     would recommend this approach.  Although you don't expose all the LDAP
>     functionality you can still leverage it under the hood of the
>     java:comp/env
>     provider to make it extremely fast.  I can help write this or add
>     Geronimo
>     developers to the LDAPd project to make it come to fruition.
>     The other approach involves the generalization of the Backend
>     interface to
>     store any kind of entry that does not necessarily need to be an
>     entry within
>     the LDAP namespace: see the attached xref file for the Backend
>     interface.
>     This way the backend apparatus is a generalized entry storage
>     subsystem that
>     could be used for any kind of namespace - directory enabled or
>     otherwise.
>     Noel Bergman and I are in the process of discussing these details
>     and anyone
>     from the Geronimo team is welcome to join us.  Basically we reduce
>     the JNDI
>     methods into a minimal set of storage oriented operations very close in
>     nature to the methods on Context and its subclasses.  This reduced
>     instruction set if you could call it that is extremely simplified
>     enabling
>     storage for entries in any namespace.  The nexus multiplexes different
>     backends for different namespaces almost federating them.
>     If a generalized provider with a pluggable NameParser is written
>     then the
>     provider can theoretically be used for any namespace.  Think of the
>     concept
>     as miniature framework for JNDI to enable storage and retrieval
>     without the
>     pain of having to implement all those methods on the Context
>     interface and
>     its subclasses.
>     These concepts are at the stage where new comers can join the
>     conversation
>     with a minimal learning curve to rapidly be able to participate.  We
>     would
>     welcome the collaboration to enable both projects to progress together.
>     Good luck & BU,
>     Alex Karasulu

View raw message