db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Matrigali <mikem_...@sbcglobal.net>
Subject Re: Concurrent access problems?
Date Thu, 31 Aug 2006 23:54:57 GMT
Does anyone know how the resource described below as a "process handle"
or "Semaphore", relates to actual things that Derby actively uses?
Actual Derby locking is done by user object allocation so I don't think
it would show as such in this tool.  It uses java synchronization 
blocks, but it is up to the jvm to release resources based on this usage.

Once the page cache fills up Derby should not really accumulate much 
more resources no matter what the number of rows.  For instance
(again once the page cache is filled), the accumulated resources to
scan a one row table are expected to be about the same as to scan
a 10 million row table.  Depending on datatypes there may be object
allocation per row, but the objects should be freed after the row
is done.  For most of the datatypes derby is coded to reuse the
objects for each row so the normal case is once the scan starts no
object allocation is necessary.

Just to understand where the problem is, do observe that the resources
are still allocated after the query is finished and the transaction
has committed?  How about after the connection is closed (but the db
still opened)?  And finally how about after the db is closed (using

Mark Hellkamp wrote:
>  <derby@...> writes:
>>The person who created the JIRA issue is the one who said "Large amounts of
>>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. 

View raw message