Объединение в пул

Раздел Создания Соединения, описанный, когда соединения создаются. Это описало, как несколько экземпляров Context могут совместно использовать то же самое соединение.

Другой тип соединения, совместно использующего поддерживаемый поставщиком услуг LDAP, вызывают объединением в пул соединения. В этом типе совместного использования поставщик услуг LDAP поддерживает пул (возможно) ранее используемых соединений и присваивает их экземпляру Context как необходимый. Когда экземпляр Context делается с соединением (закрытый, или собрал "мусор"), соединение возвращается к пулу для будущего использования. Отметьте, что эта форма совместного использования последовательна: соединение получается от пула, используемого, возвращенный к пулу, и затем, полученное снова от пула для другого экземпляра Context.

Пул соединений сохраняется на систему Среды выполнения Java. Для некоторых ситуаций объединение в пул соединения может улучшить производительность значительно. Например, только одно соединение требуется для того, чтобы обработать ответ поиска, который содержит четыре ссылки отсылки на тот же самый сервер LDAP, если объединение в пул соединения используется. Без объединения в пул соединения такой сценарий потребовал бы четырех отдельных соединений.

Остальная часть этого урока описывает более подробно, как использовать объединение в пул соединения.

Как Использовать Объединение в пул Соединения

Вы запрашиваете объединение в пул соединения, добавляя свойство, "com.sun.jndi.ldap.connect.pool" к свойствам среды, которые передают начальному конструктору контекста. Вот an example .

// Set up environment for creating initial context
Hashtable env = new Hashtable(11);
env.put(Context.INITIAL_CONTEXT_FACTORY, "com.sun.jndi.ldap.LdapCtxFactory");
env.put(Context.PROVIDER_URL, "ldap://localhost:389/o=JNDITutorial");

// Enable connection pooling
env.put("com.sun.jndi.ldap.connect.pool", "true");

// Create one initial context (Get connection from pool)
DirContext ctx = new InitialDirContext(env);

// do something useful with ctx

// Close the context when we're done
ctx.close();   // Return connection to pool

// Create another initial context (Get connection from pool)
DirContext ctx2 = new InitialDirContext(env);

// do something useful with ctx2

// Close the context when we're done
ctx2.close();   // Return connection to pool

Этот пример создает два начальных контекста по очереди. Второй начальный контекст снова использует соединение, используемое первым. Чтобы выполнить эту программу и наблюдать, как соединения получаются и возвращаются к пулу, используйте следующую командную строку.

#java -Dcom.sun.jndi.ldap.connect.pool.debug=fine UsePool

Это должно произвести вывод, который смотрит следующим образом.

Create com.sun.jndi.ldap.LdapClient@5d173[localhost:389]
Use com.sun.jndi.ldap.LdapClient@5d173
{ou=ou: NewHires, objectclass=objectClass: top, organizationalUnit}
Release com.sun.jndi.ldap.LdapClient@5d173
Use com.sun.jndi.ldap.LdapClient@5d173
{ou=ou: People, objectclass=objectClass: top, organizationalunit}
Release com.sun.jndi.ldap.LdapClient@5d173

Можно решить, когда и где использовать объединение в пул включением или исключением свойства "com.sun.jndi.ldap.connect.pool", и таким образом управлять объединением в пул на основе на контекст. В предыдущем примере, если бы Вы удалили это свойство из свойств среды прежде, чем создать второй начальный контекст, второй начальный контекст не использовал бы объединенное в пул соединение.

Провайдер LDAP отслеживает то, используется ли соединение посредством индикаций из приложения. Это предполагает, что приложение, которое поддерживает открытый дескриптор контекста, использует соединение. Поэтому, для провайдера LDAP, чтобы должным образом управлять объединенными в пул соединениями, следует быть прилежными о вызове Context.close() на контекстах, в которых Вы больше не нуждаетесь.

Плохие соединения автоматически обнаруживаются и удаляются из пула провайдером LDAP. Вероятность контекста, заканчивающегося с плохим соединением, является тем же самым независимо от того, используется ли объединение в пул соединения.

Тайм-аут создания

Пул соединений, сохраняемых поставщиком услуг LDAP, может быть ограничен в размере; это описывается подробно в Соединении, Объединяющем раздел Конфигурации в пул. Когда объединение в пул соединения было включено, и никакое объединенное в пул соединение не доступно, клиентское приложение блокирует, ожидая доступного соединения. Можно использовать свойство среды "com.sun.jndi.ldap.connect.timeout", чтобы определить, сколько времени ожидать объединенного в пул соединения. Если Вы опустите это свойство, то приложение будет ожидать неопределенно.

Это то же самое свойство также используется, чтобы определить период тайм-аута для установления соединения LDAP, как описано в разделе Создания Соединения.

Если не Использовать Объединение в пул!!

Объединенные в пул соединения предназначаются, чтобы быть снова использованными. Поэтому, если Вы планируете выполнить операции на экземпляре Context, который мог бы изменить состояние базового соединения, тогда недопустимо использовать объединение в пул соединения для того экземпляра Context. Например, если Вы планируете вызвать TLS Запуска расширенная работа на экземпляр Context, или запланировать изменить связанные с безопасностью свойства (такие как "java.naming.security.principal" или "java.naming.security.protocol") после того, как начальный контекст был создан, недопустимо использовать объединение в пул соединения для того, что экземпляр Context, потому что провайдер LDAP не отслеживает никакие подобные изменения состояния. Если Вы используете объединение в пул соединения в таких ситуациях, Вы могли бы ставить под угрозу безопасность своего приложения.