Hi Alek, > > Um why not? If you want to send a response and continue then you can > > fire the response off in another thread (or the remaining work in > > another thread). I don't think your approach makes sense as a solution > > for this scenario at all: you're saying block everything until the > > message is gone. > > > servlet writes response (201 OK) and servlet thread can be > recycled/terminated by servlet container.
Yes I know .. but what's that got to do with what Bill is suggesting? He wants to write the response and then notify executed handlers saying "hey everything was cool". In the servlet world, you can't write the response and then do something because the response gets written when you return from the servlet. > is the way it is done in AXIS2 is= not how it has to be done to handle > async WSA? is there any other way? Sorry, I didn't grok that sentence. Axis2 allows you to do Async Web services at different levels - you can hand off to another thread at the transport level, in the middle of handlers (sort of what Sandesha does), or in a message receiver (as the async message receivers do). Axis2 does not assume that a single thread is doing all the work .. as long as you have the pointer to the context hierarchy then all is fine. So my point to Bill was that the right way to exploit Axis2 is not to stick stuff on the thread when messages are flowing thru Axis2 but rather to stick stuff in the context hierarchy. The only time you should stick stuff on the thread is when you're out of Axis2 and in a world which requires it (such as when invoking an EJB). In that case, the code that's going out is responsible for cleaning up. Sanjiva.
