|
Hi! Sorry for a very long story. It is posted to both CONNECTOR-INTEREST and
EJB-INTEREST, since it may relate to both specs. My concern is if connectors are allowed to look-up and invoke an EJB,
while they (managed connections) are still in the pool. The managed connection
listens to a socket and calls an EJB when data arrives on the socket. The EJB
will then look-up the connection factory and continue using it (reading and
writing to the socket through the connection handle), until the conversation is
finished. The EJB closes the connection, which, when back in the pool,
continues to listen on the socket. Is this a supported scenario (i.e. portable)
for implementing a JCA RA? The RA is not transactional, but the EJB may be
deployed as “requires new”. That was the short version. Here goes the long version (as background
information) I’m developing a JCA RA for a middleware product that is conversational.
The protocol of the middleware is almost like a socket. Both ends may be
implemented in Java and interacting through the client- and server part of the
application through the JCA. The physical client connection may span multiple
logical interactions over the same wire (socket connection). When there is not
yet any initiated physical connection to the server (e.g. a new managed
connection is created), the protocol of the middleware triggers the server side
by posting an http request to a generic servlet (which is a component of the middleware).
The generic servlet will look up a configured connection factory (as specified
by a request parameter of the http request) and ask the factory (the servlet
uses the factory without obtaining a connection handle) for an EJB jndi home name,
which it then also looks-up, creates and calls through an architected interface
(like the jms MessageConsumer interface). It is very much the same scenario as
JMS request reply with a message driven bean at the server side. The differences
to MDB and JMS request/reply are (1) that there are not two independent queues for the request and
the response, instead, there is just an open socket and (2) the message is not delivered
as an argument to the “mdb” method, since the infrastructure does not know the
boundaries of a message (like with sockets). Instead, the jndi name of the
configured factory is passed in as argument to the “mdb”. The “mdb” will then
look-up the configured connection factory, create an application connection
handle and read the “socket” through the cci. There may be several pairs of
read/write interaction between the client and the server, until they both (as part
of an application contract) decides to close the connection handles. The socket
is still open while the client connection is in the pool. The next client-side
look-up will deliver a connection handle to a managed connection that already
has an established conversation with a server socket on which the server side
managed connection is listening (while in the pool!). When the client this time
starts a new logical conversation, the listening managed connection will notice
and look-up the home of the “mdb”. It creates the “mdb” and invokes its “onConversation”-method
(the http request and the generic servlet are not involved this time, since an
existing communication wire is reused). The “mdb” will look-up a connection and
(through proper implementation of matchManagedConnection) get a handle to the
managed connection that has just read the first bytes of a new logical
conversation. Those bytes are cached by the managed connection, so that they
can be delivered to the “mdb” upon the first call to the read-method of the
connection handle used by the “mdb”. This RA implementation will not support
sharing of connection handles. Thanks for your time! /Johan |
