RE: Concurrent access problems?

[de...@segel.com]

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:news@sea.gmane.org] On Behalf Of Mark Hellkamp
> Sent: Thursday, August 31, 2006 2:22 PM
> To: derby-user@db.apache.org
> Subject: Re: Concurrent access problems?
> 
>  <de...@...> 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.
>