[
https://issues.apache.org/jira/browse/DERBY-6398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13810014#comment-13810014
]
Knut Anders Hatlen commented on DERBY-6398:
-------------------------------------------
Hi Marty,
It would be helpful if you could post a thread dump from when the process is
stuck, so we can see where it's stuck. You can get a thread dump by connecting
to the process with the jstack tool that comes with the JDK.
Or, even better, if you manage to come up with a standalone reproducible test
case for the bug and post it here, others could study the lock-up in their own
environments. I tried to follow the steps in the bug description, but it
wouldn't reproduce in my environment.
Thanks.
> SYSCS_FREEZE_DATABASE locks-up if there are large records that haven't been
> flushed to the disk
> -----------------------------------------------------------------------------------------------
>
> Key: DERBY-6398
> URL: https://issues.apache.org/jira/browse/DERBY-6398
> Project: Derby
> Issue Type: Bug
> Components: Miscellaneous
> Affects Versions: 10.10.1.1
> Environment: Reliably demonstrated on Windows 7 with JDK 1.6.0_31
> Reporter: Marty Backe
> Fix For: 10.10.1.1
>
>
> If after writing a record that contains a large data column (>100KB), the
> FREEZE command is issued, the command never returns (Derby appears to be
> dead-locked).
> E.g. sqlStatement.executeUpdate("CALL SYSCS_UTIL.SYSCS_FREEZE_DATABASE()");
> If the CALL SYSCS_UTIL.SYSCS_CHECKPOINT_DATABASE() command is first used
> before calling FREEZE, it does not lock-up.
> It's my opinion that calling FREEZE should never result in a dead-locked
> Derby instance.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
