geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Monson-Haefel <Rich...@Monson-Haefel.com>
Subject Re: [jndi] Have we found a JNDI impl yet?
Date Sat, 30 Aug 2003 07:27:13 GMT
On 8/29/03 4:28 AM, in article
EDA2BD5C-DA13-11D7-9E84-0003934D3EA4@ioshq.com, "Alex Blewitt"
<Alex.Blewitt@ioshq.com> wrote:

> On Friday, Aug 29, 2003, at 09:24 Europe/London, Lennart Jorelid wrote:
> 
>> Hello all,
>> 
>> It is a rather big simplification to assume that the JNDI ENC will be
>> static in runtime. I have worked with quite a number of applications
>> where stuff bas been (re-)bound in the JNDI after initialization.
>> However, I agree with Richard's general thought that the JNDI has a
>> relatively small amount of bound objects, compared to the norm for
>> LDAP.
>> 
>> Using LDAP as the basis for JNDI seems idiotic - JNDI is trivial enough
>> and unspecified enough that one realizes it is not thought to be a
>> replacement for a database in a J2EE server. I say let's optimize JNDI
>> implementation for speed - but not assume read-only operation.
> 
> You also have to consider the case when a clustered system is in
> operation. Then, they are likely to need to share data that is
> installed, and a sensible back-end may need to synchronize such writes
> across a number of nodes/clusters.


In the case of clustering, LDAPd doesn't offer much value when it comes to
the JNDI ENC.  As I said, the JNDI ENC for each deployment is (a) immutable
and (b) small.  The footprint for each JNDI ENC is very small and easily
replicated across a cluster.  Using LDAPd for the JNDI ENC is like pounding
a nail with a sledgehammer.

> 
> I agree for a single-server environment, having an in-memory cache will
> be the fastest, but having a switchable JNDI server will allow both :-)
> 
> Alex.
> 
> 



Mime
View raw message