[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: PaceBatch and pipelining



> Just to put this in context...  by virtue of APP being HTTP/1.1 based,
> it already has a batching mechanism; HTTP pipelining.  PaceBatch would
> be a second batching mechanism.

I think there is a big difference between HTTP pipelining and
batching. From my understanding, and please correct me, as this is
very basic:

HTTP pipelining is designed to allow the reuse of one socket to send
multiple requests to a server. From what i read so far, the following
is true:

a) the server can not rely on any semantic correlation between the
individual parts in the pipeline
b) only used for Get/Put (at least the mozilla FAQ states so). If that
is in fact true, isn't pipelining inappropriate for batch updates?

Therefore, i see pipelining as a generic performance enhancement
model, that is unaware of what it is enhancing.

While this is great in a lot of scenarios, batch updating, as i
understand it, is a lot more related to traditional database concepts.
I envision using this to conceptually group data updates together that
belong together. It also implies that the server backend can make
assumptions on this "batch update", where with pipelining there would
be no such assumption possible (or very proprietary).

So, PaceBatch, for me, is not an HTTP pipelining replacing mechanism,
but a complementary mechanism, that will prove very useful in context
aware scenarios that are closer related to traditional database work. 
It will also provide a means for client and server programmers to
create simpler application logic for traditionally more complicated
cases. In addition, it would allow for a transition of concepts and
ideas into an HTTP unrelated realm at a later stage.

All good things, IMO, for very little cost.

Frank