3

我正在编写一个 JCA 资源适配器。我也在尝试完全理解 JCA 规范的连接管理部分。作为一个思想实验，假设这个适配器的唯一客户端是位于另一台机器上的 Swing Java 应用程序客户端。还假设资源适配器也将通过网络与其“企业信息系统”(EIS) 进行通信。

据我了解 JCA 规范，.rar 文件部署到应用程序服务器。应用程序服务器创建 .rar 文件的 ManagedConnectionFactory 接口实现。然后它要求它生成一个连接工厂，这是部署到 JNDI 的不透明对象，供用户用来获取到资源的连接。（对于 JDBC，连接工厂是 javax.sql.DataSource。）

要求连接工厂保留对应用程序服务器提供的 ConnectionManager 的引用，而后者又需要是可序列化的。这是有道理的——为了将连接工厂存储在 JNDI 中，它必须是可序列化的，并且为了保持对 ConnectionManager 的引用，ConnectionManager 也必须是可序列化的。很好，这个小对象图安装在应用程序客户端的 JNDI 树中。

这是我开始感到不安的地方。ConnectionManager——由应用程序服务器提供的应该处理连接管理、共享、池等的部分——此时是否完全存在于客户端上？它的工作之一是创建 ManagedConnection 实例，ManagedConnection 不需要是可序列化的，它提供的用户连接句柄也不需要是可序列化的。对我来说，这表明整个连接池机制被批发到应用程序客户端并填充到它的 JNDI 树中。

这是否意味着来自客户端的 JCA 交互绕过了应用程序服务器的服务器端组件？JCA API 中的网络边界在哪里？

4

1 回答 1

1

这是否意味着来自客户端的 JCA 交互绕过了应用程序服务器的服务器端组件？JCA API 中的网络边界在哪里？

AFAIK，是的。将有一个本地 JNDI，并且本地 JNDI 将返回本地连接。对于 JNDI 中的其他类型的对象，例如配置值 ( env-entry)，如果为真，则相同。当然，如果您查找 EJB，工厂会向远程 bean 返回一个代理，但据我所知 JNDI 仍然是本地的。

客户端嵌入自己的池。正如您所指出的，这意味着在客户端获得的连接将逃脱服务器端机器。

当我们开始使用分布式事务时，情况会变得更糟。客户端可能会在客户端获得UserTransaction启动和停止分布式事务的权限（但并非所有应用程序服务器都支持此功能）。事务上下文将在调用远程 EJB 期间传播。然后，分布式事务可以跨越客户端连接和服务器端连接。

根据 J2EE 理念，应用程序客户端通常不应该使用事务并直接获取连接；它应该只与远程 EJB 通信。

对于更复杂的场景，规格并不是很清楚，而且周围没有那么多信息。例如，规范不要求应用服务器向UserTransaction客户端公开。

我在这里写的内容至少适用于 Glassfish，但我不会依赖在所有应用程序服务器上一致地实现这些功能。

于 2010-03-16T09:11:32.700 回答