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.
Jan
On 8/28/03 7:40 AM, in article [EMAIL PROTECTED], "Alex Karasulu" <[EMAIL PROTECTED]> 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
