Dave Smith wrote:
> Keep the result set open, retieve from the set as necessary, probably
> using a cursor. That way if someone is doing a search that has 1 million
> records and after I display the first 10 and the client chooses the 3rd
> one, we have only created 10 objects.
No, no, no! We can't keep the result set open!
1) having open result set and open Connection for each client,
we'll end up with too many open connections and too many open result
sets (256 open cursors by default in Oracle).
2) How about transaction bounds? Can you keep cursor open after
transaction ends? I don't think so.
Oleg
> Oleg Nitz wrote:
>> Dave Smith wrote:
>>
>>>Close, but what if my initial list is 1 million records. That means that
>>>you still have to load and create 1 million pk's. I think you need to
>>>define the query and return the list. When the Collection asks for the
>>>next record or record # 10 then you not only need to load the record but
>>>also the pk.
>>>
>> Sorry, I don't understand your idea.
>> Do you propose to keep the ResultSet open?
>> Do you mean using SQL extensions like LIMIT clause?
>>
>> Oleg
>>
>>
>>>Oleg Nitz wrote:
>>>
>>
>>>>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
>>>>
>>>>
>>>>
>>
>>
>>
>>>_______________________________________________
>>>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
>>
>>
> _______________________________________________
> 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
