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 <bpendleton@amberpoint.com> wrote:
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.

Thanks for sending the thread dump, it was very interesting.

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