个人空间
本文主要描述了对JNDI的DirContext实例进行连接有效性检查的常用方法以及如何正确实现一个DirContext Pool的连接有效性检查机制。最后通过该文我们将得出解决类似问题的一个有效思路。
本文讨论的以被广泛使用的Sun JNDI LDAP Service Provider为主要对象，对于其他企业，团体或个人提供的LDAP Service Provider，本文所提供的思路同样适用。
关于Connection Pool与DirContext Pool 在JDK1.4之前的版本，被广泛使用的Sun JNDI LDAP Service Provider没有提供对连接池的支持，对于一个以JNDI为基础的LDAP前端应用来说，没有连接池对性能来说是灾难，所以我相信绝大多数系统会自己实现DirContext Pool。
JDK 1.4之后Sun提供了对Connection Pool的支持，但是这是一个比Context更底层的一个LDAP连接共享机制。在对DirContext进行close()操作后，底层的连接资源并没有被真正释放，相反在其他线程进行new InitialDirContext()时，该连接会被重用。但是该池主要专注于连接的重用，它并不能替代一个高层的DirContext实例池。比如使用Persistent Search，如果每次关闭Context，那么相关的Listener会被注销，这一般不能满足应用的要求。这种情况下就需要一个Context池用于长久的保存DirContext实例；同时一个DirContext池也会避免多次重复的new InitialDirContext()动作；而且对于非Sun的Service Provider来说，由于未必会提供这种连接池，所以往往也需要一个DirContext Pool。
连接池的连接有效性检查机制
如果实现一个更上层的DirContext 池，那么对于被重用的DirContext必须要在使用前对连接有效性进行检查，即保证被服务的每个线程将取到一个有效的DirContext实例。即在线程从池中获取实例前，DirContext Pool负责检查该实例中的连接是否有效，如果无效，则创建新的DirContext；否则使用池中实例。
具体点说，由于池中的实例会被长时间保存，如果池中的实例长时间未用导致远程LDAP服务器主动关闭了该实例关联的LDAP连接，或者由于其他原因导致物理连接失效而LDAP服务器并未当机，那么池中的实例必须要经过检查后才能交给其他线程使用。从而避免LDAP服务器处于正常工作状态但在客户端却收到CommunicationException这样一个不友好的容易造成错误理解的底层通讯异常。
其他的比如DataSource中的DB Connection Pool往往也有同样的机制，这是实现一个连接池必须的一个机制。
对性能的影响
勿庸置疑，这种有效性的检查对性能可能会造成较大的影响，因为每次与LDAP的交换事先都会进行这样的检查操作。 TAG标签 : 有效性 检查 连接 进行 如何 Time: DirContext 一个 操作
