If space reclamation cannot obtain container lock it will not retry getting the lock

• Key: DERBY-4059
• Type: Sub-task
• Status: Closed
• Resolution: Fixed
• Priority: Minor
• Assignee: Kathey Marsden
• Reporter: Kathey Marsden
• Component/s: Store
• 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: 10.5.1.1

Description

As noted in DERBY-4054 openContainerNW throws an exception if it canno get the container lock and bypasses the retry logic. See:
https://issues.apache.org/jira/browse/DERBY-4054?focusedCommentId=12673376#action_12673376

We should catch the exception and retry if we can't get the container lock. This probably won't fix the repro for DERBY-4054, but should be helpful in some user scenarios.

Comments

[Kathey Marsden]

I am trying to write a test where having the post commit retries will actually help, but am having trouble making a case. Even if I change ClobReclamationTest.xtestMultiThreadedUpdateTableLocking() to have each of the two threads update just two rows, it seems to give up after three retries. Is there any wait between retries of post commit actions or does it just loop through its todo list and retry when it is finished with its current queue?

[Kathey Marsden]

Attached is a patch for the code change so that we will retry if we can't get a container lock. I cannot however come up with a test case where it seems to make any difference. As I commented earlier, the retry seems to be too quick. I manually verified that we do retry and give up by setting derby.debug.true=DaemonTrace and looking at the derby.log.

I'd like to come up with a test case though where the retry helps before I check in.

[Kathey Marsden]

After observing the behavior with the patch and chatting with Mike, I have come to the conclusion that the three retries is just really not sufficient. We will need to something else with the retries, either have some short wait instead of no wait when trying to get locks, up the retries or do something more elaborate like Mike suggested in this comment https://issues.apache.org/jira/browse/DERBY-4055?focusedCommentId=12673436#action_12673436

I think I will go ahead and check in this fix as is as it does enable retries when getting the container lock, even though those retries aren't very useful. It should make the code more consistent for whatever solution we settle on to fix this long term. I will add a comment to the code that three retries is likely not enough.