Java连接器体系结构(JCA)中的网络边界在哪里？
我正在编写一个JCA资源适配器。同时，我也在尝试完全理解JCA规范的连接管理部分。作为一个思想实验，假设这个适配器的唯一客户机将是位于不同机器上的Swing Java Application客户机。还假设资源适配器也将通过网络与其“企业信息系统”(EIS)通信。
根据我对JCA规范的理解，.rar文件被部署到应用服务器。应用服务器创建ManagedConnectionFactory接口的.rar文件实现。然后，它要求它生成一个连接工厂，该连接工厂是部署到JNDI的不透明对象，供用户用来获得到资源的连接。(对于JDBC，连接工厂是一个javax.sql.DataSource。)
要求连接工厂保留对应用程序服务器提供的ConnectionManager的引用，而后者又要求是可序列化的。这是有意义的--为了将连接工厂存储在JNDI中，它必须是可序列化的，并且为了保持对ConnectionManager的引用，ConnectionManager也必须是可序列化的。所以很好，这个小对象图被安装在应用程序客户机的JNDI树中。
这就是我开始反胃的地方。ConnectionManager--由应用服务器提供的负责处理连接管理、共享、池化等的组件--此时是否完全存在于客户端？它的工作之一是创建ManagedConnection实例，ManagedConnection不需要是可序列化的，处理它的用户连接也不需要是可序列化的。对我来说，这意味着整个连接池机制被批量发送到应用程序客户端，并填充到它的JNDI树中。
这是否意味着来自客户端的JCA交互绕过了应用服务器的服务器端组件？JCA API中的网络边界在哪里？
回答 1
Stack Overflow用户
发布于 2010-03-16 17:11:33
这是否意味着来自客户端的
交互绕过了应用服务器的服务器端组件？JCA API中的网络边界在哪里？
AFAIK，是的。将有一个本地JNDI，本地JNDI将返回本地连接。对于JNDI中的其他类型的对象，也是如此，例如配置值(env-entry)。当然，如果查找EJB，工厂会向远程bean返回一个代理，但据我所知，JNDI仍然是本地的。
客户端嵌入自己的池。正如您所指出的，这意味着在客户端获得的连接将避开服务器端机器。
当我们开始使用分布式事务时，情况会变得更糟。客户端可以获得一个UserTransaction来启动和停止客户端上的分布式事务(不是所有的应用程序。然而，服务器支持这一点)。事务上下文将在调用远程EJB期间传播。然后，分布式事务可以跨越客户端连接和服务器端连接。
根据J2EE的原理，应用程序客户端通常不应该使用事务并直接获得连接；它应该只与远程EJB通信。
对于更复杂的场景，规范并不是很清楚，周围也没有太多信息。例如，该规范并不强制应用服务器向客户端公开UserTransaction。
我在这里写的内容至少适用于Glassfish，但我不会依赖于跨所有应用服务器的这些功能的一致实现。
https://stackoverflow.com/questions/2237389
复制相似问题
腾讯云开发者
