I have few doubts regarding the http requests handled by tomcat.
say I'm client,
I make http request and suddenly close connection when our code is run still. what will happen to the request.
How to handle transaction if i have to roll back entire transaction.
Have any Idea on how tomcat handles the request, tomcat keeps all in memory.
If I have a broken request and nobody is listining to it , how the situation is handled. situation is handled.
Hi Azahrudhin Mohammad, What i know from my previous experience is that once you make any request and it is handled by server, then you cant know if the connection has been closed by user until and unless you have some client which can confirm that client has closed this connection. And that will be possible after the client will get the response.
One thing which seems to be a solution for me is ask client for the confirmation, otherwise rollback your transaction.
Thank you for the reply. We cannot go to each client for asking confirmation, If we publish wsdl some body is using our service
then it will be very difficult.
Client ------> Request -------> MyWebservice in tomcat --------> do some processing db hit ----------> once processed the response will be sent back.
Say if moment user has submitted the request connection is lost , how my application will come to know the connection is lost i should rollback the operation.
HTTP does not run continuous conversation. In HTTP, the request is sent down as a unit and the response to that request comes back (after processing) as a unit. The network connections are the permanent listening port in Tomcat (8080 or whatever) for the incoming request and a randomly-selected reply port on the client to receive the response. The client selects its reply port and a different port is used (for security reasons) for each reply.
If you make a request and the request transmission gets broken, the incomplete request will be discarded. If the server makes a response and the reply port stops receiving, the response will timeout and fail. If the reply port should signal trouble, the response transmission will be aborted.
Because the response may go through several layers of buffering, application logic will not know how much data was successfully transmitted, and because of the application architecture (and because an HTTP operation may require multiple request/response operations, some of which may be in parallel), there is no provision in J2EE for handling network-related problems. Anything network-related is up to the server (Tomcat) and the OS.
So what that means, in short, is that you don't code network-related error handling as such into J2EE webapps. However, you should definitely make your application operations transactional.
Since request/response is an atomic operation, if the client doesn't receive a successful response, then (and only then), the client might need to check to see if the server performed the operation successfully.
Another option, where multiple requests are required to handle a transaction, you may need a longer-term (XA) transaction manager on the server and a set of transaction-bounding requests as part of your web service-supplied methods.
Customer surveys are for companies who didn't pay proper attention to begin with.
Hi Tim Holloway,
Thank you for the reply, as per the post we need not to handle such kind of scenario , if at all we want also we should go for transaction manager you mean to say.
But is that the only way for the client he can check the transaction status in next request.
I'm not sure I understood that, but basically when you make a web service call that performs one or more database transactions, you should return with a value that indicates whether the operation was a success or not.
If the failure was due to causes outside of your webapp, then the web service call itself will fail and instead of the usual HTTP 400 OK response, you'll get some other HTTP response code (such as 503 if the web service server logic threw an exception).
As long as you got the "OK" response, you can trust the success/failure code that your own logic returned. Otherwise, you would have to send another web service request to inquire about whether things were done successfully in the previous request. Of course, if you have a really bad network connection, this request can also fail, so you'd have to re-issue the status query request until it came back successfully.