我正在编写JCA资源适配器。我也是这样，试图完全理解JCA规范的连接管理部分。作为一个思想实验，假装此适配器的唯一客户端将是位于不同计算机上的Swing Java应用程序客户端。还假设资源适配器也将通过网络与其“企业信息系统”（EIS）进行通信。
据我了解JCA规范，.rar文件已部署到应用程序服务器。应用程序服务器创建.rar文件的ManagedConnectionFactory接口实现。然后它要求它生成一个连接工厂，它是部署到JNDI的不透明对象，供用户用来获取与资源的连接。 （对于JDBC，连接工厂是javax.sql.DataSource。）
要求连接工厂保留对应用程序服务器提供的ConnectionManager的引用，而ConnectionManager又需要Serializable。这是有道理的 - 为了将连接工厂存储在JNDI中，它必须是可序列化的，并且为了使它保持对ConnectionManager的引用，ConnectionManager也必须是可序列化的。很好，这个小对象图安装在应用程序客户端的JNDI树中。
这是我开始感到不安的地方。 ConnectionManager - 由应用程序服务器提供的应该处理连接管理，共享，池化等的部分 - 此时完全出现在客户端上吗？其中一项工作是创建ManagedConnection实例，而ManagedConnection不需要是Serializable，并且用户连接处理它们也不需要序列化。这告诉我整个连接池机器批发到应用程序客户端并填充到其JNDI树中。
这是否意味着来自客户端的JCA交互绕过了应用服务器的服务器端组件？ JCA API中的网络边界在哪里？
答案 0 :(得分：1)
这是否意味着JCA 来自客户端的互动 绕过服务器端的组件 应用服务器？在哪里 JCA API中的网络边界？
AFAIK，是的。将有一个本地JNDI，本地JNDI将返回本地连接。对于JNDI中的其他类型的对象，如果为true，则为相同的配置值（env-entry）。当然，如果你查找一个EJB，工厂会将一个代理返回给远程bean，但是根据我的知识，JNDI仍然是本地的。
客户端嵌入自己的池。这意味着，正如您所指出的那样，在客户端中获得的连接将逃离服务器端机器。
当我们开始使用分布式事务时，情况变得更糟。客户端可以获得UserTransaction以在客户端启动和停止分布式事务（但并非所有应用服务器都支持此操作）。事务上下文将在调用远程EJB期间传播。然后，分布式事务可以跨越客户端连接和服务器端连接。
根据J2EE理念，应用程序客户端通常不应使用事务并直接获取连接;它应该只与远程EJB通信。
关于更复杂的情况，规范并不是很清楚，并且没有太多的信息。例如，规范不要求应用服务器将UserTransaction暴露给客户端。
我在这里写的内容至少适用于Glassfish，但我不会依赖所有应用程序服务器上这些功能的一致实现。