db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Charlie Hubbard <charlie.hubb...@gmail.com>
Subject Re: Deadlocked in Log2File
Date Thu, 18 Feb 2010 19:42:32 GMT

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

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

>  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
> thanks,
> bryan

View raw message