db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kathey Marsden (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-4054) Multithreaded clob update with exclusive table locking causes table growth that is not reclaimed
Date Fri, 13 Feb 2009 21:14:59 GMT

    [ 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) {
            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
> ------------------------------------------------------------------------------------------------
>                 Key: DERBY-4054
>                 URL: https://issues.apache.org/jira/browse/DERBY-4054
>             Project: Derby
>          Issue Type: Bug
>          Components: Store
>    Affects Versions:,,,,
>            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.

View raw message