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