You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Kathey Marsden (JIRA)" <ji...@apache.org> on 2009/02/12 18:52:00 UTC
[jira] Created: (DERBY-4054) Multithreaded clob update with
exclusive table locking causes table growth that is not reclaimed
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.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.
[jira] Updated: (DERBY-4054) Multithreaded clob update with
exclusive table locking causes table growth that is not reclaimed
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Knut Anders Hatlen updated DERBY-4054:
--------------------------------------
Urgency: Normal
Triaged for 10.5.2.
> 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.1.1
> 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.
[jira] Commented: (DERBY-4054) Multithreaded clob update with
exclusive table locking causes table growth that is not reclaimed
Posted by "Kathey Marsden (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12673019#action_12673019 ]
Kathey Marsden commented on DERBY-4054:
---------------------------------------
Committed a test that demonstrates the issue with revision 743820 store/ClobReclamationTest.xtestMultiThreadedUpdateTableLocking()
Enable this test to reproduce the problem.
> 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.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.
[jira] Commented: (DERBY-4054) Multithreaded clob update with
exclusive table locking causes table growth that is not reclaimed
Posted by "Kristian Waagan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12874581#action_12874581 ]
Kristian Waagan commented on DERBY-4054:
----------------------------------------
Is BLOB affected by this problem as well?
> 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.1.1
> 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.
[jira] Updated: (DERBY-4054) Multithreaded clob update with
exclusive table locking causes table growth that is not reclaimed
Posted by "Kathey Marsden (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kathey Marsden updated DERBY-4054:
----------------------------------
Affects Version/s: 10.1.3.1
10.2.2.0
10.3.3.0
10.4.2.0
Derby Categories: [High Value Fix]
> 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.
[jira] Commented: (DERBY-4054) Multithreaded clob update with
exclusive table locking causes table growth that is not reclaimed
Posted by "Kathey Marsden (JIRA)" <ji...@apache.org>.
[ 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.