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-user@db.apache.org
Subject: Re: advice for client/server application
Date: Thu, 23 Mar 2006 18:15:42 -0500
User-Agent: KMail/1.8.3
References: <200603221819.56215.ryan@ostrich-emulators.com>
 <4421EA6D.1080201@sun.com>
In-Reply-To: <4421EA6D.1080201@sun.com>
MIME-Version: 1.0
Content-Disposition: inline
Message-Id: <200603231815.42320.ryan@ostrich-emulators.com>
Content-Type: text/plain;
  charset="utf-8"
Content-Transfer-Encoding: 7bit

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

-- 
"Son I am able," she said, "though you scare me."
"Watch," said I, "Beloved." I said, "Watch me scare you though."
Said she: "Able am I son."
	-- They Might Be Giants