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. Sachin Chitale wrote: > > Hi, > > To give you a background of what I was testing: > > We have process that uses database as our guranteed message store. To give > a > stress test to Derby, this program was run to store about 70k+ messages. > Then > a subscriber was started to fetch the messages. But it seems that the > database > has stopped responding to the requests. > > Initially I was able to get message count using: > ij> select count(*) from M_20070129MESSAGES; > 1 > ----------- > 54598 > > After ~15 minutes. > 1 row selected > ij> select count(*) from M_20070129MESSAGES; > ERROR 40XL1: A lock could not be obtained within the time requested > > -- View this message in context: http://www.nabble.com/Derby-process-taking-up-more-than-20--of-cpu-for-more-than-5hrs-with-only-one-user-connected.-tf3619391.html#a10112431 Sent from the Apache Derby Users mailing list archive at Nabble.com.
