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. Thanks, Charlie On Wed, Feb 17, 2010 at 6:12 PM, Bryan Pendleton <[email protected]>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 > or SYSCS_UTIL.SYSCS_CHECKPOINT_DATABASE? > > If you are calling SYSCS_FREEZE_DATABASE, is it possible that you > have some path through your system which fails to subsequently call > SYSCS_UNFREEZE_DATABASE? > > thanks, > > bryan > >
