Christopher, Thanks for your insight and suggestions. Running in a separate JVM would give me the control I need to keep the connections open. I'm pursuing that approach now and looking at the links you provided. I'm also considering an EJB 2.0 approach, using stateful session EJBs for maintain these 2 socket connections. The EJB would connect on one socket and keep reusing the connection to the backend server, but the tricky part, would be that listener socket connection it would need to set up so the backend server can send async notifications at any later time. Under EJB 2.0, can a stateful session bean listen on a socket?
I'm also thinking in terms of performance, is it better to run multiple threads doing this in a JVM contained server, or have lots of EJBs created for each connection pair (could be thousands). This is the direction of my research now, if anyone has tips or insights I would appreciate greatly! Paula Young Paula Young wrote: > > one listener socket that listens for async > notifications from the other host). > Servlets aren't really meant for that sort of thing. Remember: the servlet (and session) are really only guaranteed to be available while there's a request coming in for the servlet. As soon as the request is over, the servlet (or the session) might go away for a while (or be moved to another machine, or be partially recycled, etc) Or not. It's up to the servlet container. If you want a server thread, it's better to start up another JVM and run the server where you have full control. The server thread can notify the servlet of updates by just calling it using a URLConnection. That makes things much cleaner all around. But it means running another JVM. If you feel you just have to spawn a thread from a servlet, there are more details, and some links, at: http://www.distributopia.com/servlet_stuff/background_threads.txt > I've looked around for info on what types of objects are > 'ok' to persist in the session and what types are definite > no-nos, and couldn't find any info pro or con if persisting > UNIX resources like sockets (connect and listen)in > the session is even possible. Check out the latest servlet spec, there's a section called "Sessions" that has good, easy to read info. Your problem (if I'm understanding correctly) is similiar to the problem of keeping database connections open across requests. So if you do some research about how that works (connection per request, connection pools, etc), most of it should apply. Try "connection pool" as well as "resource pool" as search terms in google and the archives of this list. You've got to be careful. If the webapp is marked as distributable, then a different machine might handle the request every time, even for the same session, so you're not going to be able to use the same socket. If your webapp is not distributable, then you still need to be very careful to catch the end of the session, so you can shut down the connections. -- Christopher St. John [EMAIL PROTECTED] DistribuTopia http://www.distributopia.com ___________________________________________________________________________ To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff SERVLET-INTEREST". Archives: http://archives.java.sun.com/archives/servlet-interest.html Resources: http://java.sun.com/products/servlet/external-resources.html LISTSERV Help: http://www.lsoft.com/manuals/user/user.html ___________________________________________________________________________ To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff SERVLET-INTEREST". Archives: http://archives.java.sun.com/archives/servlet-interest.html Resources: http://java.sun.com/products/servlet/external-resources.html LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
