| Frequently Asked Questions

## Contexts

> #### What is the relationship between a context and the connection to the LDAP server?

> When you create an `InitialContext`, `InitialDirContext`, or `InitialLdapContext` by using the LDAP service provider, a connection is set up immediately with the target LDAP server. Any contexts and `NamingEnumeration`s that are derived from this initial context share the same connection as the initial context.

> For example, if you invoke `Context.lookup()` or `Context.listBindings()` from the initial context and get back other contexts, then all of those contexts will share the same connection. If you create a new initial context, then it will have its own connection.

> When you change environment properties that are related to a connection, such as the principal name or credentials of the user, the context on which you make these changes will get its own connection (if the connection is shared). Contexts that are derived from this context in the future will share this new connection, but those that previously shared the context's connection are not affected (that is, they continue to use the old connection).

> Similarly, if you use `LdapContext.reconnect()`, then the `Context` instance on which you invoke this method will get its own connection if the connection is shared.

> #### How do I close the connection to the LDAP server?

> To close the connection to the server, invoke `Context.close()` on all contexts originating from the initial context that created the connection. Make sure that all `NamingEnumeration` have been completed. For those context and enumeration objects that are no longer in scope, the Java runtime system will eventually garbage collect them, thus cleaning up the state that a `close()` would have done. To force the garbage collection, you can use the following code.

> >     Runtime.getRuntime().gc();
> >     Runtime.getRuntime().runFinalization();

> #### Is the context safe for multithreaded access, or do I need to lock/synchronize access to a context?

> The answer depends on the implementation. This is because the `Context` and `DirContext` interfaces do not specify synchronization requirements. Sun's LDAP implementation is optimized for single-threaded access. If you have multiple threads accessing the same `Context` instance, then each thread needs to lock the `Context` instance when using it. This also applies to any `NamingEnumeration` that is derived from the same `Context` instance. However, multiple threads can access different `Context` instances (even those derived from the same initial context) concurrently without locks.

> #### Why does the LDAP provider ignore my security environment properties if I do not set the `Context.SECURITY_CREDENTIALS` (`"java.naming.security.credentials"`) property or set it to the empty string?

> If you supply an empty string, an empty `byte`/`char` array, or `null` to the `Context.SECURITY_CREDENTIALS` environment property, then an anonymous bind will occur even if the `Context.SECURITY_AUTHENTICATION` property was set to `"simple"`. This is because for simple authentication, the LDAP requires the password to be nonempty. If a password is not supplied, then the protocol automatically converts the authentication to `"none"`.

> #### Why do I keep getting a `CommunicationException` when I try to create an initial context?

> You might be talking to a server that supports only the LDAP v2. See the Miscellaneous lesson for an example of how to set the version number.

> #### I'm seeing some strange behavior. How do I find out what's really going on?

> Try using the `"com.sun.jndi.ldap.trace.ber"` environment property. If the value of this property is an instance of `java.io.OutputStream`, then trace information about BER buffers sent and received by the LDAP provider is written to that stream. If the property's value is `null`, then no trace output is written.

> For example, the following code will send the trace output to `System.err`.

> >     env.put("com.sun.jndi.ldap.trace.ber", System.err);

> #### How do I use a different authentication mechanism such as Kerberos?

> First, you need to have Java classes that support Kerberos and/or GSSAPI. Then, you need to follow the instructions in the Security lesson for making a SASL mechanism implementation available to the LDAP provider.

| Frequently Asked Questions