This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
A colleague and I recently had the following discussion.
A servlet gets a request, completes it's processing, completes the service method and then there is a network error. For example, the servlet does seven or eight large DB operations that takes a total of about 5 seconds, during that five seconds somebody kicks out the network connection on the App server. He said that the servlet could then catch the error and we'd be able to log the information that the client never got the response.
I said that it wasn't possible since the service method would still complete and then try and send out response...and that it would never know that there was a network error and that client didn't get the response.
TCP is a guarenteed protocol, so the second you screw that connection around, if the buffer has not cleared and socket loses the connection it will throw an exception... If it was UDP you would be right.
... but on a servlet container like Tomcat I dont think the application will see it unless you trap the exception... the message will be in some obscure log file.
The reason they cant crash the app is because if the servlet is taking a long time and the user gets bored and closes the browser, the same think happens... but its just a log message.