I see no reason you would need your servlet to stay in memory. As long
as it is alive when needed (that is when requests arrive) it's enough.
Maybe you problem is that it does much than serving request, like
running background thread, send message to people and so on. Then you
might simply need to separate the servlet (part that answer a client)
from the service object (part that handle various thread). The service
object could be started/stopped by a simple servletContextListener and
attached to JNDI. The servlet would then request that object from JNDI.
If you don't like to use JNDI you can still attach it to application scope.
This will be more easy to maintain and more performant than delegating
work to another server and add an other row of TCP/IP packets.
Kamil Burzynski a écrit :
Hello,
Please read the other responses to this thread, since they are correct that
there is no guarantee. However, the current implementation of TC (3.3-6.0)
will not unload a Servlet unless the entire context is reloaded (with a
slight exception for JSP pages). But then you are programming against
Tomcat itself, in an area where there is no guarantee that it won't change
in the future, and it may not work if you try to move to another Servlet
container.
Yeah, I was afraid of getting such answer, actually ;) In my project it
would be enough to code against current version of Tomcat, though I
would like a clean solution. So, it seems, that I'll do standalone
server and then webapp will connect to it via some protocol (I am not
familiar with java world enough to know if any good rpc is there - most
probably it is).
Thanks for all answers.
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
