The LDAP context implementation. Implementation is not thread-safe. Caller must sync as per JNDI spec. Members that are used directly or indirectly by internal worker threads (Connection, EventQueue, NamingEventNotifier) must be thread-safe. Connection - calls LdapClient.processUnsolicited(), which in turn calls LdapCtx.convertControls() and LdapCtx.fireUnsolicited(). convertControls() - no sync; reads envprops and 'this' fireUnsolicited() - sync on eventSupport for all references to 'unsolicited' (even those in other methods); don't sync on LdapCtx in case caller is already sync'ing on it - this would prevent Unsol events from firing and the Connection thread to block (thus preventing any other data from being read from the connection) References to 'eventSupport' need not be sync'ed because these methods can only be called after eventSupport has been set first (via addNamingListener()). EventQueue - no direct or indirect calls to LdapCtx NamingEventNotifier - calls newInstance() to get instance for run() to use; no sync needed for methods invoked on new instance; LdapAttribute links to LdapCtx in order to process getAttributeDefinition() and getAttributeSyntaxDefinition() calls. It invokes LdapCtx.getSchema(), which uses schemaTrees (a Hashtable - already sync). Potential conflict of duplicating construction of tree for same subschemasubentry but no inconsistency problems. NamingEnumerations link to LdapCtx for the following: 1. increment/decrement enum count so that ctx doesn't close the underlying connection 2. LdapClient handle to get next batch of results 3. Sets LdapCtx's response controls 4. Process return code 5. For narrowing response controls (using ctx's factories) Since processing of NamingEnumeration by client is treated the same as method invocation on LdapCtx, caller is responsible for locking.