This is a question about Glassfish's implementation of the JCA specification, especially where application clients are concerned.
The JCA specification goes to great lengths to point out which of its classes and interfaces must implement or extend Serializable. In general, these are classes and interfaces that get installed into JNDI.
But I'm not clear where the network boundaries are. Let's look at javax.sql.DataSource and java.sql.Connection as a way to point out my probable misunderstandings.
DataSource is an example of a connection factory (little c, little f) in JCA parlance. The spec says that any implementation of it must be Serializable so that it can live in JNDI.
But Connection is an example of a connection handle, and is not Serializable.
Now, a connection handle, in JCA parlance, is required to keep a reference to the ManagedConnection instance that created it. And a ManagedConnection is not Serializable either.
Armed with all this, then, here's my question: how is it, then, that a Java application client, running on a separate machine, with a network cloud between it and the application server, with its own JNDI tree--how is it that this client can avoid dragging in the entire Glassfish connection pooling machinery? Or, to put it another way, if the connection factory (DataSource, living on the client) tells the application server by way of its ConnectionManager to create new ManagedConnection instances (presumably on the server), then how do those non-Serializable ManagedConnection instances make it to the client so that their non-Serializable Connections that they vend also make it to the client?
More briefly: where are the network boundaries in a JCA resource adapter?
Thanks,
Laird
[Message sent by forum member 'ljnelson' (ljnelson_at_gmail.com)]
http://forums.java.net/jive/thread.jspa?messageID=385938