Best patterns for providing an iterator via thrift RPC

[Stuart Reynolds]

I'd like to provide access to something like a database iterator via a
thrift API (e.g. iterate through 1M+ DB records). This requires state
to be maintained on the server, although only for the duration of the
thrift TCP connection. (ie. you could argue that the server might
still be considered stateless).

Here's my first pass:

----
struct RPCIteratorID {
   int id;
   int dataTypeId;
}

// Get an iterator of type T1. 0 = means no results.
RPCIteratorID queryT1( queryParams );

// supply the iterator id. list.size!=maxResults == end.
list<T> getNext_T2( RPCIteratorID iter, int maxResults );


RPCIteratorID queryT2( queryParams );
list<T2> getNext_T2( RPCIteratorID iter, int maxResults );


RPCIteratorID queryT3( queryParams );
list<T3> getNext_T3( RPCIteratorID iter, int maxResults );
...
void closeIterator( RPCIteratorID iter );
----

If the TCP socket timesout or is close, the server calls closeIterator
for all open iterators on the connection.

Are there better design patterns for this?

- Stu