Mailing-List: contact derby-user-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Derby Discussion" <derby-user@db.apache.org>
Received-SPF: pass (asf.osuosl.org: local policy)
From: Ryan P Bobko <ryan@ostrich-emulators.com>
To: "Derby Discussion" <derby-user@db.apache.org>
Subject: Re: advice for client/server application
Date: Thu, 23 Mar 2006 18:52:29 -0500
User-Agent: KMail/1.8.3
References: <200603221819.56215.ryan@ostrich-emulators.com>
 <200603231815.42320.ryan@ostrich-emulators.com> <44232FDD.9000603@sun.com>
In-Reply-To: <44232FDD.9000603@sun.com>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200603231852.29163.ryan@ostrich-emulators.com>

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.