db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sachin Chitale <sachit...@yahoo.com>
Subject Re: Derby process taking up more than 20% of cpu for more than 5hrs with only one user connected.
Date Sat, 21 Apr 2007 03:18:08 GMT

hofhansl <lhofhansl@...> writes:

> If another process is constantly updating the table, the reads may not be
> successful in getting a read-lock and eventually time out.
> You can try 
> > select count(*) from M_20070129MESSAGES WITH UR;
> WITH UR allows for uncommitted reads.
> You may also have to increase the lock escalation threshold (number of locks
> after which Derby decides to get a table lock). Something like:
> derby.locks.escalationThreshold=10000 in derby.properties.

I would love to do it, if I could login. Infact now I am even unable to stop 
the server. probably simply because stop script is unable to connect itself.

I am still unable to understand the amount of time and CPU that this process is 

Further the memory seems to be behaving properly. It has a typical GC pattern 
of any server. (After around 300+MB it falls back to around 100MB)


View raw message