db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Matrigali (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DERBY-6780) change conglomerate cache to handle concurrency and alter table add column calls.
Date Thu, 11 Dec 2014 16:58:13 GMT

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

Mike Matrigali commented on DERBY-6780:
---------------------------------------

DERBY-6774 fixed this problem for access by heap post commit background threads.  This issue
is about fixing it for concurrent users access to heap tables.  Concurrent access to btree
indexes should not be at issue currently as those Conglomerates can not currently change after
being created.

> change conglomerate cache to handle concurrency and alter table add column calls.
> ---------------------------------------------------------------------------------
>
>                 Key: DERBY-6780
>                 URL: https://issues.apache.org/jira/browse/DERBY-6780
>             Project: Derby
>          Issue Type: Bug
>          Components: Store
>    Affects Versions: 10.12.0.0
>            Reporter: Mike Matrigali
>
> The store maintains a "conglomerate cache" for performance reasons, to
> avoid having to go to disk and rebuild the Conglomerate structure every
> time there is some interaction with a table.  It maintains this cache across
> all users in the db and across transactions.
> The store's conglomerate cache as originally designed expected the
> "Conglomerate" data structure to be static.   At issue is that support was
> added to this data structure to track the number and types of columns in
> the conglomerate.  Initially alter table add column always resulted in
> a new underlying "Conglomerate" being created so the originaly expectation
> was still valid.
> At some point some versions of alter table add column were implemented
> that did not require a rebuild of all of the underlying conglomerates, 
> including the base table.  This meant that the data in the conglomerate
> cache could go out of date.  The fix implemented for this was to have 
> alter table get exclusive lock on table, update the cache as it did it's work,
> and invalidate the entire cache on abort.   When abort happened the code
> did not have enough information to invalidate just what it needed.  
> DERBY-4057 added more concurrency to the testing of alter table and
> showed a problem with the current code.  The current normal path 
> for store interaction is to first get the Conglomerate from the cache and then
> use information in the data structure to "open" the table with proper locking.
> This allows a small window if concurrent alter table add column (and maybe
> drop column) are happening. 
> various problems come to mind:
> 1) a concurrent thread might get conglomerate with uncommitted alter 
>     table info, and then wait on alter table to finish.  If the alter table aborts
>     it will be left with wrong information.
> 2) a concurrent thread might come in after alter table abort invalidates
>      the cache, but before the abort finishes.  This will then load a bad 
>      version into the cache for others to see later.  This is what was 
>      happening with background concurrent issues in DERBY-6774, and fixed
>      only for the background threads.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message