Interrupt request serving in tomcat

[Fabio Scibilia]

Dear all,

I am writing business logic of a web app and I am enquiring about the possibility of Tomcat to brutally stop request-serving threads.
My question is: considering a pseudo Java method code like this:

public void function()
{
// 1) JDBC code to insert new rows to a table

// 2) notifies the insertion event to some observers
}

Is it possible for some reason (that I can't figure out in this moment), that Tomcat stops the thread in the middle between 1) and 2) ??? As you can imagine, statements 1) and 2) MUST be atomic from a business point of view. My concern is about the threads are user-request serving threads: what happens if the user aborts the connection or whatever else? I don't know if Tomcat guarantees the completion of the threads independetly of the user (or connection) behaviour.

I am native C++/Linux programmer and in POSIX environments you can instruct the kernel to not destroy a running in thread while inside some specific code statement, creating in this way a "securely executed code" zone. Probably, a similar concept exists in Java and/or Tomcat (sorry my leak of experience in Java).

Thanks for your help.

Fabio

[William Brogden]

I would call this a Transaction Processing problem.

Because the servlet API is entirely designed around request/response processing, you can not guarantee Thread completion (whatever that means in this context). If your program tries to write output to the response but the user has closed the client browser you get an exception and the Thread terminates.

Bill

[Fabio Scibilia]

Hi William,

thanks for your clear reply. However, I suppose that cause I am executing that code in business layer, before trying to send any output to the user, I will not get any exception. My main concern is more on Java thread behaviour: it is possible to guarantee for a thread to be not destroyed while inside a certain statement (transaction). Looking at java tutorial I discovered that other threads (and than I am enquiring about Tomcat) may call Thread.destroy() and destroy my thread wherever it is executing. This method however is deprecated (may Tomcat invoke the destroy() for some reason???).

Thanks, I can move this thread on some other topic if you think it is not a problem of tomcat

Fabio

[Tim Holloway]

J2EE web applications must not terminate threads. If it doesn't say that explicitly in the spec, you can consider it said implicitly in that the spec expressly and explicitly forbids creating threads.

The threads used to service an HTTP service request belong to Tomcat, not to the application. Requests should be processed and completed, which returns the thread to the Tomcat thread pool. If you terminate the thread instead of returning it, your server's life will be short, brutish and nasty.

An inherent assumption - or perhaps requirement - for HTTP request processing is that the request/response cycle should be as short as possible so that A) response will be returned to the user/client with minimal delay, and that B) common resources, such as the Tomcat processor threads, should not be tied up and thus unavailable for other users. If you need to do work that cannot conform to these constraints, you should construct an out-of-band processing engine for that kind of work. This engine is typically started via a ContextListener at webapp startup, and usually has an associated work queue so that it may spawn whatever threads it needs independently of the HTTP request/response processor threads. HTTP requests may queue up work and hand it off to the engine, but they may not call the long-running engine code directly (otherwise, what's the purpose?)

The engine thread(s) may spawn cancellable threads, but forcible termination of a thread is never a good idea, which is why the primary methods originally in Java were deprecated. If the reason for wanting to terminate a thread has to do with getting hung on a request to an external network-based service - including database requests - the preferred method of termination is to adjust the timeout parameter for that service (if there is one). For long-running processes in local code, it's safest to have the process check periodically for a "cancel" flag that can be set by the requester so that the process will be able to short-circuit its normal work and clean itself up in an orderly manner.

[Fabio Scibilia]

Hi Tim,

your answer is was I expected. In my scenario, one user adds a new record into a table (over a Tomcat servlet thread) and then invokes a method to notify the observers. The notification mechanism consists in the pushing of a new event message into a queue (so, Tomcat thread is not blocked at all). The observers are consumer threads popping from that queue. They are instantiated in the ContextListener at the startup of the system and they always work in the background. My only concern was about the eventual brutal deletion of the Tomcat thread just in the between the JDBC and the notification code due to some unpredictable Tomcat policy. Now I understand that is not possible cause threads are giving back to the Tomcat's thread pool.

Then, everything looks fine to me now.

Thanks for your replies

Fabio

[Aleksander Wlodarczyk]

Fabio Scibilia wrote:Hi Tim,

your answer is was I expected. In my scenario, one user adds a new record into a table (over a Tomcat servlet thread) and then invokes a method to notify the observers. The notification mechanism consists in the pushing of a new event message into a queue (so, Tomcat thread is not blocked at all). The observers are consumer threads popping from that queue. They are instantiated in the ContextListener at the startup of the system and they always work in the background. My only concern was about the eventual brutal deletion of the Tomcat thread just in the between the JDBC and the notification code due to some unpredictable Tomcat policy. Now I understand that is not possible cause threads are giving back to the Tomcat's thread pool.

Then, everything looks fine to me now.

Thanks for your replies

Fabio

Hi Fabio,

Have You considered things like power shortage or administrator killing tomcat?
It may happen between 1) and 2) so You cannot depend on it not being interrupted.