Hi John,
Thanks for the info.
You're right -- I should have said "blocking" instead of "synchronous".
And maybe, as you say, the bottom line is that you can't have both -- you
can't have a blocking solution and also solve the network timeout problem.
As for the point about transactions and batching, here's some pseudocode
that hopefully explains what I was trying to say:
// demarcation not tied to the network (good)
// no batching; client-side wait time grows with the data size (bad)
handlePost()
{
// read all the request bytes from the wire
Record[] records = readRequestBody();
// this will start a transaction and run the processing
List results = processRecords(records);
// processing complete, send results back down the wire
sendResponseBody(results);
}
// demarcation tied to the network (bad)
// there is a ceiling on the client-side wait time (good)
handlePost()
{
boolean done = false;
List resultList = new ArrayList();
// we have to start the txn sooner because of our batching approach
Transaction txn = beginTxn();
try
{
while (!done)
{
// read a batch of the request bytes from the wire
Record[] records = readRequestBody(BATCH_SIZE);
// run the processing for this batch (client waits)
List results = processRecords(records);
// store the results so far
resultList.addAll(results);
// peek at the request body to see if there is any data left
done = isRequestBodyEmptyYet();
}
// all data has been read from the wire
// all processing is done
// all results are stored in memory
// now we complete the txn
commitTxn(txn);
txn = null;
}
finally
{
if (txn != null)
rollbackTxn(txn);
}
// send results back down the wire
sendResponseBody(results);
}
-----Original Message-----
From: John D. Mitchell [mailto:[email protected]]
Sent: Wednesday, February 25, 2009 9:22 PM
To: [email protected]
Subject: Re: detecting that client aborted or timed out
On Wednesday 2009.02.25, at 16:51 , Luis Saenz wrote:
[...]
> Yeah, your suggestion to use the post/redirect/get pattern is a
> great way to solve this issue, but it violates my first stated
> constraint -- a synchronous solution. :)
It is a synchronous solution -- it's just not a blocking solution.
That actually makes it easier to deal with relative to some network
problems.
> The only reason I want a synchronous solution is for simplicity --
> to support lowest common denominator clients such as curl, without
> requiring the user of the API to write a script with logic such as
> what you propose below. However, no argument that adding this
> asynchronous complexity would solve the problem.
I missed your original post so forgive my ignorance but you seem to
have multiple, conflicting desires... Do you want a single blocking
request/response or do you want to be more sensitive/reactive to more
problematic network issues?
In terms of your mention of chunking things, I'm afraid I must be
missing something as it seems like you're making things more
complicated in terms of trying to do too much in one step. Can you
perhaps explain what you're really trying to do -- particularly with
respect to what your notions of the transactions?
Thanks,
John
------------------------------------------------------
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=12309
99
------------------------------------------------------
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1234231
