I do have to ask, what does it mean to emulate an ostrich?
David
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
transfer.
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.
David
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?
ry
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?
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
