Чтобы процитировать спецификацию JCA (версия 1.0, но 1.5 имеет тот же текст, и я предполагаю, что в более новых версиях он также есть):
Адаптер ресурсов необходим для реализации интерфейса ManagedConnectionFactory.
Требуется, чтобы класс реализации ManagedConnectionFactory расширял реализацию методов hashCode и equals, определенных в классе java.lang.Object. Эти два метода используются сервером приложений для структурирования пула соединений в зависимости от реализации. Реализация методов equals и hashCode должна основываться на полном наборе свойств конфигурации, которые делают экземпляр ManagedConnectionFactory уникальным и специфичным для экземпляра EIS.
и
Сервер приложений может использовать дополнительные параметры для поиска и критерии сопоставления, используемые при управлении его пулом соединений. Эти параметры могут быть специфическими для EIS или сервера приложений. Методы equals и hashCode, определенные как для ManagedConnectionFactory, так и для ConnectionRequestInfo, упрощают управление и структурирование пула соединений сервером приложений.
В спецификации больше ничего об этом не сказано (кроме указания того же требования для некоторых других интерфейсов).
Поскольку общая идея состоит в том, что реализации управляемого соединения предоставляются поставщиками (например, поставщиками баз данных) и что сервер приложений может объединять ресурсы (например, ManagedConnection экземпляров), то предложение "Эти два метода используются приложением сервера для структурирования своего пула соединений в зависимости от реализации" Я могу только предположить, что это было сделано для упрощения реализации, например, для использования в HashMap или HashSet и т. д. Например, создание двух экземпляров ManagedConnectionFactory с идентичными свойствами приведет к имеют одинаковый результат для equals и hashCode и, следовательно, могут использовать один и тот же пул.
Кажется, это подтверждается следующей цитатой из той же спецификации:
Сервер приложений может разбивать свой пул на ManagedConnectionFactory экземпляров (и, таким образом, на каждый экземпляр EIS). Сервер приложений может гарантировать (специфическим для реализации способом), что он всегда будет разделять пулы соединений с точностью не менее ManagedConnectionFactory экземпляров.
Спецификация JCA, по-видимому, подразумевает, что соединения с одной системой должны обрабатываться одной управляемой фабрикой соединений (хотя я полагаю, что это не указано явно). Для этого потребуется найти один единственный ManagedConnectionFactory на основе его свойств.
Например, ядро Jaybird (JDBC-драйвер Firebird, который я поддерживаю) представляет собой реализацию JCA (что, кстати, может быть настоящей головной болью). Первоначальная реализация Jaybird была разработана Дэвидом Дженксом, который также написал JCA-реализацию JBoss. В драйвере equals и hashCode используются несколькими способами:
ManagedConnectionfactory хранит статический WeakHashMap, указывающий экземпляр на самого себя. Это используется для канонизации экземпляра (если экземпляр уже существует с такими же equals и hashCode, возвращается этот экземпляр).- Реализация
java.sql.Driver org.firebirdsql.jdbc.FBDriver сохраняет WeakHashMap от ManagedConnectionfactory до (без пула) реализации javax.sql.DataSource. Когда создается новое соединение, этот источник данных извлекается (или создается иным образом) для создания фактического соединения.
- Когда
ManagedConnectionFactory десериализуется, метод readResolve возвращает канонизированную версию (см. 1), если она уже была на карте.
В качестве примечания: спасибо, что подняли этот вопрос; похоже, что текущая реализация в Jaybird имеет здесь ошибку, поскольку обе карты содержат прямую и косвенную сильную ссылку на фабрику управляемых соединений, что делает использование слабой хеш-карты довольно бесполезным.
person
Mark Rotteveel
schedule
20.10.2014
