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: domain of gcaddu-derby-user@m.gmane.org
 designates 80.91.229.2 as permitted sender)
To: derby-user@db.apache.org
From: Mark Hellkamp <mark.hellkamp@theplatform.com>
Subject: Re: Concurrent access problems?
Date: Thu, 31 Aug 2006 19:21:31 +0000 (UTC)
Lines: 29
Message-ID: <loom.20060831T191234-589@post.gmane.org>
References: <loom.20060831T100449-666@post.gmane.org>
 <20060831143837.C0BE32515F@dbrack01.segel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
User-Agent: Loom/3.14 (http://gmane.org/)
Sender: news <news@sea.gmane.org>

 <derby@...> writes:
> 
> [mjs] 
> The person who created the JIRA issue is the one who said "Large amounts of
> data".
> 
> 10K rows of 9 columns, is not a "large amount" of data.
> 
> While Mark posted that he tried using MySQL instead of Derby, one has to ask
> if he tried running the query independent of his app.
> 
> The point is that there are a lot of variables that can impact performance.
> Spring and Hibernate are two of them.
> 
> So unless someone introduced a "bug" in the latest release, I'm a bit
> skeptical of the issue.
> 
> 

The application is querying about 24 tables in all for each request that comes
in. The number of rows in the tables range from 0 to over 30,000 in my current
testing. As I add more concurrent request threads the database continues to
allocate additional process handles (this is on Windows). Using Process Explorer
(from www.sysinternals.com) I can see that the Derby process is allocating
Semaphores and does not appear to ever release them. As more data is added to
the tables, the process handle count continues to grow even though the results
of the queries remain the same. Derby appears to be allocating resources
(locks?) but never cleaning them up.