We do not call SYSCS_UTIL.SYSCS_FREEZE_DATABASE or SYSCS_UTIL.SYSCS_CHECKPOINT_DATABASE.
We do perform backups using CALL SYSCS_UTIL.SYSCS_BACKUP_DATABASE(?). However, in this particular test case the backup hasn't been run. So, for this particular test case the backup_database stored proc hasn't been called.
This is a new application that uses derby so I can't say if this is new behavior for this application or not. We don't do any replication. This seems to happen fairly frequently if I try and process a very large data set for my application (70,000 entries). For smaller data set sizes it seems to work out ok (7500 entries).
I encountered this from within my profiler so I decided to try this outside the profiler, and I didn't encounter any locking issue. If I do this within my profiler I see it frequently. For right now I think it's the profiler unless I can reproduce this outside my profiler.
I'm using Derby 10.5.3.
On Wed, Feb 17, 2010 at 6:12 PM, Bryan Pendleton <firstname.lastname@example.org>
Thanks for sending the thread dump, it was very interesting.
I'm sometimes getting deadlocks in Log2File where all my worker threads are getting blocked, but I can't figure out which monitor they are blocked on.
I agree with you, it's not clear what is blocking these threads,
at least from the thread dump.
I think this could be a Derby bug. How often does it happen? Is it
a new behavior?
Looking at the source code, LogToFile.flush() has some complicated
synchronization logic which interacts with the backup/checkpoint methods.
Does your application perform a backup?
Does your application involve replication?
Does your application ever call SYSCS_UTIL.SYSCS_FREEZE_DATABASE
If you are calling SYSCS_FREEZE_DATABASE, is it possible that you
have some path through your system which fails to subsequently call