db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David W. Van Couvering" <David.Vancouver...@Sun.COM>
Subject Re: advice for client/server application
Date Fri, 24 Mar 2006 00:02:48 GMT
I do have to ask, what does it mean to emulate an ostrich?


Ryan P Bobko wrote:
> Thanks for the advice. That's probably what I needed to hear.
> ry
> On Thursday 23 March 2006 06:31 pm, David W. Van Couvering wrote:
>>Yes, I see what you're saying, you're rewriting JDBC extended with file
>>You could take the Derby source and extend it so that you can do file
>>transfer functionality, but then you're stuck with your own fork of
>>JDBC.  And I'm sorry to say that the Derby community would likely not
>>accept your changes back (someone correct me if I'm wrong) because there
>>would be non-standard extensions to JDBC, and we strive to be
>>standards-compliant as a community.
>>Personally, I would just open two connections: one for JDBC work and one
>>for file transfer.  Keep them separate.
>>Ryan P Bobko wrote:
>>>Thanks for the advice, but I'm not sure if that will help. I now realize
>>>what makes me uneasy about my architecture is that I feel like I'm
>>>rewriting JDBC little by little just so I can have my file-moving piece
>>>on top of it. JDBC works great for my purposes, so my preference would be
>>>to remove my custom protocol whenever possible. Is it feasible to extend
>>>the JDBC API? Or will that just be more trouble than it's worth?
>>>I realize I just changed my question. Any more advice?
>>>On Wednesday 22 March 2006 07:23 pm, 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?
>>>>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
>>>>>expect from a "full-blown" database (nested selects, correlated
>>>>>subqueries, stored procedures, you name it), it's suprised me. I love
>>>>>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.

View raw message