Hi John, Thanks again for your great response -- very much appreciated.
Additional comments and responses below. ---------------------------- (John) > The separation of the client with the post/redirect/get pattern just > changes the *client* to a non-blocking 'future'-ish model. I.e., if > you use a thread pool model with a thread dedicated to processing the > entire set of checks and behaviors to handle the POSTed data vs. if > that's split out ala a SEDA approach, for example. (Lu) Exactly -- that's what I'm hoping to avoid, even though I agree it is a better design. The reason I want to avoid it is because I expect a non-trivial percentage of my clients not to have the skill to write a client like this. So I want to support a very simple REST client like curl, and provide a simple, non-blocking API spec. ---------------------------- (Lu) >> I’m still curious if anyone has any ideas for detecting and handling >> a client-side “Control-C” gracefully, or any practical tips for >> implementing long-running and transactional POST operations. (John) > Hmm... "Gracefully" is a whole 'nother question. What does that mean > for you? Are you wanting to try and detect the client hitting the > stop button and somehow abort the transaction that's already in > flight? Or something else? Yes -- exactly that. I was hoping that someone smarter than me would have a solution to detect the client hitting the stop button (or timing out) so that I can abort the transaction that is in-flight. (And especially in the situation where the transaction is happening after all the request body bytes have been read, but before the response body bytes have been written.) ---------------------------- (John) > As in most discussions of long-running "transactions"... Don't. Split > things out into a series of transactional steps. Think "workflows", > "proposals", and "compensations" rather than one single big-bang > transaction. Agreed. ---------------------------- Thanks, - Lu ------------------------------------------------------ http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1234326
