Derby
  1. Derby
  2. DERBY-4054

Multithreaded clob update with exclusive table locking causes table growth that is not reclaimed

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 10.1.3.1, 10.2.2.0, 10.3.3.0, 10.4.2.0, 10.5.1.1
    • Fix Version/s: None
    • Component/s: Store
    • Urgency:
      Normal
    • Issue & fix info:
      High Value Fix

      Description

      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.

        Issue Links

        There are no Sub-Tasks for this issue.

          Activity

          Gavin made changes -
          Workflow jira [ 12452498 ] Default workflow, editable Closed status [ 12802584 ]
          Kathey Marsden made changes -
          Labels derby_triage10_5_2 derby_triage10_9 derby_triage10_11
          Mike Matrigali made changes -
          Labels derby_triage10_5_2 derby_triage10_5_2 derby_triage10_9
          Hide
          Mike Matrigali added a comment -

          derby 10.9 triage. no changes.

          Show
          Mike Matrigali added a comment - derby 10.9 triage. no changes.
          Kathey Marsden made changes -
          Link This issue is related to DERBY-5356 [ DERBY-5356 ]
          Kathey Marsden made changes -
          Link This issue is blocked by DERBY-5356 [ DERBY-5356 ]
          Kathey Marsden made changes -
          Link This issue is blocked by DERBY-5356 [ DERBY-5356 ]
          Kathey Marsden made changes -
          Labels CLOB derby_triage10_5_2
          Hide
          Kristian Waagan added a comment -

          Is BLOB affected by this problem as well?

          Show
          Kristian Waagan added a comment - Is BLOB affected by this problem as well?
          Kristian Waagan made changes -
          Labels CLOB
          Knut Anders Hatlen made changes -
          Urgency Normal
          Hide
          Knut Anders Hatlen added a comment -

          Triaged for 10.5.2.

          Show
          Knut Anders Hatlen added a comment - Triaged for 10.5.2.
          Dag H. Wanvik made changes -
          Issue & fix info [High Value Fix]
          Myrna van Lunteren made changes -
          Affects Version/s 10.5.1.1 [ 12313771 ]
          Affects Version/s 10.5.0.0 [ 12313010 ]
          Hide
          Kathey Marsden added a comment -

          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.

          Show
          Kathey Marsden added a comment - 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.
          Kathey Marsden made changes -
          Link This issue is related to DERBY-4050 [ DERBY-4050 ]
          Kathey Marsden made changes -
          Field Original Value New Value
          Derby Categories [High Value Fix]
          Affects Version/s 10.1.3.1 [ 12311953 ]
          Affects Version/s 10.4.2.0 [ 12313345 ]
          Affects Version/s 10.2.2.0 [ 12312027 ]
          Affects Version/s 10.3.3.0 [ 12313142 ]
          Hide
          Kathey Marsden added a comment -

          Committed a test that demonstrates the issue with revision 743820 store/ClobReclamationTest.xtestMultiThreadedUpdateTableLocking()
          Enable this test to reproduce the problem.

          Show
          Kathey Marsden added a comment - Committed a test that demonstrates the issue with revision 743820 store/ClobReclamationTest.xtestMultiThreadedUpdateTableLocking() Enable this test to reproduce the problem.
          Kathey Marsden created issue -

            People

            • Assignee:
              Unassigned
              Reporter:
              Kathey Marsden
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:

                Development