On Thursday 2009.02.26, at 10:36 , Luis Saenz wrote:
[...]
> 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.
Which network problem are you particularly worried about? It sounds
like you have multiple worries (client abort and latency being two
big, obvious ones).
> 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);
> }
Separate each "record" into it's on request/response.
Bonus: configure pipeline support
Bonus: open multiple concurrent connections
If the updates to multiple records all have to go together than think
about doing tentative updates of each record and tying each batch
together with a "changeset" (aka transaction aka generation) id (but
you'll still have to deal with concurrent/conflicting updates, etc.).
Hope this helps,
John
------------------------------------------------------
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1234301
