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-4055) Space may not be reclaimed if row locks are not available after three retries
Date Fri, 13 Feb 2009 22:20:59 GMT

    [ https://issues.apache.org/jira/browse/DERBY-4055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12673401#action_12673401
] 

Kathey Marsden commented on DERBY-4055:
---------------------------------------

For the row lock case, changing container_rlock.lockRecordForWrite to wait for the lock seemed
to correct the problem, but I don't know what ramifications that might have.
 
Always requeuing the request  if we couldn't get the lock seemed to work only if I put a sleep
in before closing the connection to give the post commit tasks a chance to catch up. I had
to sleep over a minute to get 10,000 updates by each of two threads to catch up.  Even then
I had a lot of free pages, so the space would ultimately get reclaimed, but  we'd still use
a lot of space.  In a very active system I could also see the post commit tasks piling up
and becoming a resource issue, so this solution doesn't seem like a good option.

Questions:

1) Is it expected that the cleanup tasks will just be aborted if if the connection is closed
or is that another bug?

2) Anyone have any ideas on an acceptable approach to make sure our reclamation  gets done
without causing unacceptable lock contention?


> Space may not be reclaimed if  row locks are not available after three retries 
> -------------------------------------------------------------------------------
>
>                 Key: DERBY-4055
>                 URL: https://issues.apache.org/jira/browse/DERBY-4055
>             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
>         Attachments: derby.log.T_RawStoreFactoryWithAssert
>
>
> In a multithreaded clob update where the same row is being updated, space will not be
reclaimed.  The offending code is in ReclaimSpaceHelper:
> 	RecordHandle headRecord = work.getHeadRowHandle();
> 		if (!container_rlock.lockRecordForWrite(
>                 tran, headRecord, false /* not insert */, false /* nowait */))
> 		{
> 			// cannot get the row lock, retry
> 			tran.abort();
> 			if (work.incrAttempts() < 3)
>             {
> 				return Serviceable.REQUEUE;
>             }
> 			else
>             {
>                 // If code gets here, the space will be lost forever, and
>                 // can only be reclaimed by a full offline compress of the
>                 // table/index.
>                 if (SanityManager.DEBUG)
>                 {
>                     if (SanityManager.DEBUG_ON(DaemonService.DaemonTrace))
>                     {
>                         SanityManager.DEBUG(
>                             DaemonService.DaemonTrace, 
>                             "  gave up after 3 tries to get row lock " + 
>                             work);
>                     }
>                 }
> 				return Serviceable.DONE;
>             }
> 		}
> If we cannot get the lock after three tries we give up.  The reproduction for this issue
is in the test store.ClobReclamationTest.xtestMultiThreadUpdateSingleRow().
> This issue also used to reference the code below and has some references to trying to
get a reproduction for that issue, but that work has moved to DERBY-4054.  Please see DERBY-4054
for work on the container lock issue.
> ContainerHandle containerHdl = 
> 			openContainerNW(tran, container_rlock, work.getContainerId());
> 		if (containerHdl == null)
> 		{
> 			tran.abort();
> 			if (SanityManager.DEBUG)
>             {
>                 if (SanityManager.DEBUG_ON(DaemonService.DaemonTrace))
>                 {
>                     SanityManager.DEBUG(
>                         DaemonService.DaemonTrace, " aborted " + work + 
>                         " because container is locked or dropped");
>                 }
>             }
> 			if (work.incrAttempts() < 3) // retry this for serveral times
>             {
> 				return Serviceable.REQUEUE;
>             }
> 			else
>             {
>                 // If code gets here, the space will be lost forever, and
>                 // can only be reclaimed by a full offline compress of the
>                 // table/index.
>                 if (SanityManager.DEBUG)
>                 {
>                     if (SanityManager.DEBUG_ON(DaemonService.DaemonTrace))
>                     {
>                         SanityManager.DEBUG(
>                             DaemonService.DaemonTrace, 
>                             "  gave up after 3 tries to get container lock " + 
>                             work);
>                     }
>                 }
> 				return Serviceable.DONE;
>             }
> 		}	

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message