Something doesn't sound right. What you're describing is that the query is doing a sequential scan of the table.
> -----Original Message----- > From: news [mailto:[EMAIL PROTECTED] On Behalf Of Mark Hellkamp > Sent: Thursday, August 31, 2006 2:22 PM > To: [email protected] > Subject: Re: Concurrent access problems? > > <[EMAIL PROTECTED]> 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. >
