这不是一个真正的问题，但更多的问题是JCA专家让我看到了JCA规范的一个方面。
我试图理解为什么JCA要求资源适配器bean和托管连接工厂必须实现equals()和hashCode()。
IMO资源适配器或托管连接工厂是应用程序服务器管理的对象，至少在托管环境中是这样。 因此，它们离EJB，Servlet，CDI托管bean不远，应用程序服务器负责管理实例。 资源适配器类或受管连接工厂类的实例数由其部署直接定义。
那么为什么有人在这些课程上需要equals()和hashCode()？
我从来没有做过任何其他实现，而是调用超级实现，直到现在它才能正常工作。
但肯定声纳并不是真的很欣赏这一点。
答案 0 :(得分：1)
引用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实例上对其池进行分区 （从而在每个EIS实例上）。应用程序服务器可以选择保证（以特定于实现的方式）始终以至少每ManagedConnectionFactory个实例粒度对连接池进行分区。
JCA规范似乎暗示与单个系统的连接应该由单个受管连接工厂处理（尽管我认为它没有明确说明）。这需要一种方法来根据其属性找到单个ManagedConnectionFactory。
作为一个例子，Jaybird的核心（我维护的Firebird JDBC驱动程序）是一个JCA实现（顺便说一句，这可能是一个真正的痛苦）。 Jaybird的最初实现是由David Jencks编写的，他也编写了JBoss的JCA实现。在驱动程序中，ManagedConnectionFactory和equals以多种方式使用：
hashCode保持静态ManagedConnectionfactory将实例指向自身。这用于规范化实例（如果实例已存在且具有相同的WeakHashMap和equals，则返回该实例。hashCode实施java.sql.Driver保持org.firebirdsql.jdbc.FBDriver从WeakHashMap到（非合并）ManagedConnectionfactory实施。创建新连接时，将检索（或以其他方式创建）此数据源以创建实际连接。javax.sql.DataSource时，ManagedConnectionFactory方法将返回规范化版本（请参阅1），如果它已经在地图中。作为旁注：感谢你提出这个问题;看起来Jaybird中的当前实现有一个错误，因为两个映射都保持对托管连接工厂的直接和间接强引用，这使得使用弱哈希映射相当无用。
答案 1 :(得分：0)
如果查看规范，您会找到原因：https://jcp.org/aboutJava/communityprocess/mrel/jsr322/index.html
6.5.3.2要求 资源适配器必须提供ManagedConnectionFactory接口的实现。 需要ManagedConnectionFactory实现类扩展hashCode的实现，并且等于java.lang.Object中定义的方法。应用程序服务器使用这两种方法以特定于实现的方式构造其连接池。 equals和hashCode方法实现应基于一组完整的配置属性，这些属性使ManagedConnectionFactory实例对EIS实例唯一且特定。