db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan P Bobko <r...@ostrich-emulators.com>
Subject Re: advice for client/server application
Date Thu, 23 Mar 2006 23:52:29 GMT
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

-- 
There are three ways to get something done: do it yourself, hire
someone, or forbid your kids to do it.

Mime
View raw message