hofhansl <[EMAIL PROTECTED]> 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 taking. 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) thanks sachin
