Question

I am writing a JCA resource adapter. I’m also, as I go, trying to fully understand the connection management portion of the JCA specification. As a thought experiment, pretend that the only client of this adapter will be a Swing Java Application Client located on a different machine. Also assume that the resource adapter will communicate with its “enterprise information system” (EIS) over the network as well.

As I understand the JCA specification, the .rar file is deployed to the application server. The application server creates the .rar file’s implementation of the ManagedConnectionFactory interface. It then asks it to produce a connection factory, which is the opaque object that is deployed to JNDI for the user to use to obtain a connection to the resource. (In the case of JDBC, the connection factory is a javax.sql.DataSource.)

It is a requirement that the connection factory retain a reference to the application-server-supplied ConnectionManager, which, in turn, is required to be Serializable. This makes sense–in order for the connection factory to be stored in JNDI, it must be serializable, and in order for it to keep a reference to the ConnectionManager, the ConnectionManager must also be serializable. So fine, this little object graph gets installed in the application client’s JNDI tree.

This is where I start to get queasy. Is the ConnectionManager–the piece supplied by the application server that is supposed to handle connection management, sharing, pooling, etc.–wholly present on the client at this point? One of its jobs is to create ManagedConnection instances, and a ManagedConnection is not required to be Serializable, and the user connection handles it vends are also not required to be Serializable. That suggests to me that the whole connection pooling machinery is shipped wholesale to the application client and stuffed into its JNDI tree.

Does this all mean that JCA interactions from the client side bypass the server-side componentry of the application server? Where are the network boundaries in the JCA API?

Answer 1

Does this all mean that JCA
interactions from the client side
bypass the server-side componentry of
the application server? Where are the
network boundaries in the JCA API?

AFAIK, yes. There will be a local JNDI and the local JNDI will return local connections. Same if true for other kind of object in the JNDI, such a configuration value (env-entry). Of course, if you look up an EJB, the factory returns a proxy to the remote bean, but the JNDI is still local to my knowledge.

The client embeds its own pool. This means, as you pointed out, that connections obtained in the client will escape the server-side machinery.

It gets even worse when we start to play with distributed transactions. A client may obtain a UserTransaction to start and stop distributed transactions on the client-side (not all app. server supports this, though). The transaction context will be propagate during calls to remote EJB. A distributed transaction may then span client-side connections and server-side connections.

According to the J2EE philosophy, an application client should normally not use transactions and obtain connection directly; it should solely communicate with remote EJB.

The specs are not really clear about more complicated scenario and there isn’t that many information around. The spec do for instance not mandate the application server to expose the UserTransaction to the client.

What I wrote here applies to Glassfish at least, but I would not rely on a consistent implementation of such features across all application servers.