db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Veaceslav Chicu ...@infologic.fr>
Subject Re: advice for client/server application
Date Thu, 23 Mar 2006 08:17:38 GMT
java.sql.Statement

public void setFetchSize(int rows)
                  throws SQLException

    Gives the JDBC driver a hint as to the number of rows that should be
fetched from the database when more rows are needed for this ResultSet
object. If the fetch size specified is zero, the JDBC driver ignores the
value and is free to make its own best guess as to what the fetch size
should be. The default value is set by the Statement object that created
the result set. The fetch size may be changed at any time.

    Parameters:
        rows - the number of rows to fetch
    Throws:
        SQLException - if a database access error occurs or the
condition 0 <= rows <= this.getMaxRows() is not satisfied
    Since:
        1.2

best regards,
Slavic

David W. Van Couvering wrote:
> A common way client applications working with large result sets have
> handled the "too much memory" problem that I've seen is to send the
> results over in chunks.  Instead of sending all 120,000 records in one
> response, just send 100 or 1,000.  The client processes those 1,000
> records, throws them away, and get the next 1,000.
> 
> Would that work for you?
> 
> David
> 
> Ryan P Bobko wrote:
>> Hi List,
>> First of all, I can't say enough how impressed I've been with Derby.
>> Every time I've thought this embedded wouldn't be able to do something
>> I expect from a "full-blown" database (nested selects, correlated
>> subqueries, stored procedures, you name it), it's suprised me. I love it.
>>
>> This isn't strictly a Derby question, but I'm hoping for some advice
>> or suggestions with how to procede. I've been working on an
>> application that is a sort of half-database, half-FTP client/server
>> setup. The protocol I've implemented between the client and server
>> lets the app do things like run queries, but also move files around
>> based on those results. Or insert rows into the database based on
>> where files have moved to. Files can be moved from the server to
>> client and vice versa.
>>
>> Things have been working just fine, except that when I run queries,
>> the server process does all the work and returns the results as a
>> vector of string arrays. It's never sat well with me--and as you can
>> imagine--now that the dataset is getting pretty big (120.000-4KB rows
>> returned for some queries), I'm using too much memory.
>>
>> What I'd like to do is get my jdbc connection object onto the client
>> so I don't have to "package" everything up when returning resultsets.
>> The question is how?  My first idea was to just use derby's network
>> server and write the file protocol separately, but I'd prefer to stick
>> with just one socket if I can.
>> Advice? Thanks for your time.
>> ry
>>


Mime
View raw message