[
https://issues.apache.org/jira/browse/DERBY-4054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12673376#action_12673376
]
Kathey Marsden commented on DERBY-4054:
---------------------------------------
So the interesting thing here is that in ReclaimSpaceHelper.reclaimSpace() the
call to
openContainerNW(tran, container_rlock, work.getContainerId());
does not return null if it can't get the lock right away as I would have
expected. It actually throws an Exception:
ERROR 40XL1: A lock could not be obtained within the time requested
at java.lang.Throwable.<init>(Throwable.java:67)
at
org.apache.derby.iapi.error.StandardException.<init>(StandardException.java:80)
at
org.apache.derby.iapi.error.StandardException.<init>(StandardException.java:69)
at
org.apache.derby.iapi.error.StandardException.newException(StandardException.java)
at
org.apache.derby.impl.store.raw.data.BaseContainerHandle.useContainer(BaseContainerHandle.java:823)
at
org.apache.derby.impl.store.raw.data.BaseDataFileFactory.openContainer(BaseDataFileFactory.java:735)
at
org.apache.derby.impl.store.raw.data.BaseDataFileFactory.openContainer(BaseDataFileFactory.java:551)
at
org.apache.derby.impl.store.raw.xact.Xact.openContainer(Xact.java:1313)
at
org.apache.derby.impl.store.raw.data.ReclaimSpaceHelper.openContainerNW(ReclaimSpaceHelper.java)
at
org.apache.derby.impl.store.raw.data.ReclaimSpaceHelper.reclaimSpace(ReclaimSpaceHelper.java:246)
at
org.apache.derby.impl.store.raw.data.BaseDataFileFactory.reclaimSpace(BaseDataFileFactory.java:1256)
at
org.apache.derby.impl.store.raw.data.ReclaimSpace.performWork(ReclaimSpace.java:148)
at
org.apache.derby.impl.services.daemon.BasicDaemon.serviceClient(BasicDaemon.java:331)
at
org.apache.derby.impl.services.daemon.BasicDaemon.work(BasicDaemon.java:668)
at
org.apache.derby.impl.services.daemon.BasicDaemon.run(BasicDaemon.java:394)
at java.lang.Thread.run(Thread.java:735)
This exception gets throw right away. It doesn't wait for the timeout.
This exception causes us to leave reclaimSpace and somehow this exception gets
gobbled up somewhere and never reported, so the space does not get reclaimed
and we don't get a report of a problem I haven't quite figured out where we
decide to ignore the exception and move on. If I run in the debugger the
exception just get's thrown and not ignored for some reason.
If I hack in the change:
ContainerHandle containerHdl = null;
try {
containerHdl =
openContainerNW(tran, container_rlock,
work.getContainerId());
} catch (StandardException e) {
e.printStackTrace();
if (e.getSQLState().equals("40XL1"))
containerHdl = null;
}
Then I will proceed and will hit the message " gave up after 3 tries to get
container lock " described in DERBY-4055.
Based on this finding I think I am going to rearrange the Jira issues a little
bit. I am going to make DERBY-4055 just be for the row lock case and keep this
one for the table lock case.
> Multithreaded clob update with exclusive table locking causes table growth
> that is not reclaimed
> ------------------------------------------------------------------------------------------------
>
> Key: DERBY-4054
> URL: https://issues.apache.org/jira/browse/DERBY-4054
> Project: Derby
> Issue Type: Bug
> Components: Store
> Affects Versions: 10.1.3.1, 10.2.2.0, 10.3.3.0, 10.4.2.0, 10.5.0.0
> Reporter: Kathey Marsden
>
> If I do a multithreaded clob update which gets an exclusive table lock on the
> table, space will not be reclaimed. This case is similar to DERBY-4050
> except that the test gets an exclusive table lock and the growth happens
> whether or not the update is synchronized. I will add a disabled test for
> this to ClobReclamationTest and reference this bug.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
