Hi,
Yes, I am working on this. Here is the algorithm. The list of PK
values are loaded at first and stored to LRU cache of query results on
server, the id of the list is passed to client. When client requests
some CMP field, the list id and index in the list of the given entity
is passed to server. Next N entities are loaded from DB (SQL statement
has the form "SELECT ... WHERE pk=? OR pk=? ...") and returned to
client. When client requests the same CMP field for next N entities,
no interaction with with server is done to serve this request.
Oleg
Peter Fagerlund wrote:
> on 1-09-24 05.36, Dain Sundstrom at [EMAIL PROTECTED] wrote:
>> Maybe I am stupid, but I have have no idea what this means.
> I do not think so ! ... it is me being unclear -perhaps ... -this means, A
> pattern is great, and especially so, if there is a good implementation
> "template" I can use, and customise for my application ...
> A page_by_page_iterator should have an idee of the amount of records it is
> capeble to display for its user -say 100.000.000 -when a user request a list
> s/he should get a list of some -then perhaps the implementation prefetch
> some more data in close perimeter to where in the index the user is
> navigating ...
> -get metadata
> -fetch some data to list
> - display the list
> -prefetch some more
> -wait for new input
> Also a centralised cache for all users of the iterator -that can act
> according to how static the data is ... would help ...
> A page_by_page_iterator for really large datasets would work best in tandem
> with a lighter db that has a prebuilt index ! ...
> /peter_f
> _______________________________________________
> Jboss-development mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-development
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
