Persisting sockets in an EJB (session bean)
I've been trying to figure out the best way, if it's even possible, to persist a socket connection in my session bean and I could use some help. :-)
Basically, when my bean is first called, it opens a socket connection to an outside server. Then it performs an operation by sending a command over and receiving a reply. After the operation has been performed, the bean is done with it's work, for now.
The problem comes from the fact that the socket connection must now be maintained and not closed. I need to ensure that the socket doesn't go away between now and the next time the bean is called.This is because you actully have to "log in" to the outside server, and if you close the connection you are assumed to have "logged out", which is not what I want.
Does anyone know how I can persist the socket from one bean instantiation to another? Or have a recommendation of where to look? Everything I read talks about how any open sockets must be closed because the bean will not maintain any open resources.
Thanks for your help!
[1075 byte] By [
Anakha_] at [2007-9-26 2:21:36]
We thought about just trying to persist the state of the bean. But, the issue we came up against is how do you persist a socket? And if we did find a way, won't it just "close" the connection to the server? And closing the connection is what we're trying to not do.
The idea of sending a "keep-alive" also came up, but we didn't pursue it too much. There is nothing around to actually call the bean to tell it to stick around. At least not in our architecture.
One way we seem to have found, and are going to try out as soon as we can, is to create a Stateful Session Bean that uses bean-managed transactions using the UserTransaction interface. I know it's not really recommended, but I found the suggestion in J2EE book in a discussion about Long Transactions. And then a reference in another Enterprise JavaBeans book mentions how a bean that is the middle of a transaction (begin() was called but no commit() or abort()) then Passivate() will not be called on the bean until the transaction is complete. This seems to mean that the bean will stay around, and any members of the bean (namely the socket) will too.
Has anyone ever tried such a concept? Or looked at it?
True, the socket may be closed by the server it's connected to (not in my case, but can happen in normal cases), the connection may be lost due to network error on either end (which can happen in my case), etc.
But, when I go to write to the socket's input stream, using a PrintWriter for instance, I will catch an exception if the socket has crapped out. The same goes if I try to read from the socket's output stream and the socket has crapped out. So, we have thought about these scenarios, and others, and hope that we can handle any situations that come up.
Unfortunately, there is no other choice for this particular component (at least in regards to having to keep the socket open). The socket connection must stay alive over a long period, and from bean method call to bean method call. Basically, when we first create the socket and log in, we have to keep that socket open and in existence or we are logged out. And since we still have work to do (over who knows how long of a period), we can't let that happen.
Now, the reason behind choosing a stateful session bean is I believe that's the only type that allows you to have such a transaction implementation. A stateless session bean would require you to call commit() before exiting the method that is called, which will then allow the bean to be "passivated". Then, if Passivate() is called, the connection has to go away and we our right back where we were. An entity bean is meant to be used by various clients, and give a single representative view of the resource. But, we don't want just one view (socket), but many. Each front end user will have their own connection to use over the lifetime of their operation.
Hey... but isn't this what makes this all fun!
