[
https://issues.apache.org/jira/browse/HBASE-12751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14642109#comment-14642109
]
stack commented on HBASE-12751:
-------------------------------
Studying the patch more, I have better idea what is going on. It seems mvcc is
carrying what was sequenceid in HRegion now so my comment above on two counters
is off. Also deleted a comment that wasn't helping.
Would it be better if mvcc didn't know anything about memstore? Should we be
asking mvcc to advance memstore...
{code}
mvcc.advanceMemstore(key.getWriteEntry());
{code}
... though I see that mvcc used to know about memstore so this is nit (I just
saw we used to have completeMemstoreInsertWithSeqNum)
We dropped an optimization when we let go of the below and instead just say
true for getRowLock.. Or was it something that just didn't work? (Or looks like
the semantic changed from waitFor to whether a read or write lock?)
{code}
boolean shouldBlock = numReadyToWrite == 0;
{code}
For sure memstoreCells (removed) is same as...
{code}
for (int j=0; j<familyMaps.length;j++) {
for(List<Cell> cells:familyMaps[j].values()) {
...
{code}
No chance that what is passed to Store to add gets filtered or ends up being
subset for any reason?
The comment below no longer applies? It is dropped in the patch.
{code}
// there may be some in-flight transactions, but they won't be made
visible since they are
// either greater than flush seq number or they were already dropped
via flush.
// TODO: If we are using FlushAllStoresPolicy, then this can make edits
visible from other
// stores while they are still in flight because the flush commit
marker will not contain
// flushes from ALL stores.
getMVCC().advanceMemstoreReadPointIfNeeded(flush.getFlushSequenceNumber());
{code}
In mvcc it is memstoreRead for the read point. The name seems to say it applies
to memstore only. It does not apply to hfiles? HFiles carry sequenceids on
edits and in metadata.
Will be back to do final 1/3rd of patch.
> Allow RowLock to be reader writer
> ---------------------------------
>
> Key: HBASE-12751
> URL: https://issues.apache.org/jira/browse/HBASE-12751
> Project: HBase
> Issue Type: Bug
> Components: regionserver
> Affects Versions: 2.0.0, 1.3.0
> Reporter: Elliott Clark
> Assignee: Elliott Clark
> Fix For: 2.0.0, 1.3.0
>
> Attachments: HBASE-12751-v1.patch, HBASE-12751-v10.patch,
> HBASE-12751-v10.patch, HBASE-12751-v11.patch, HBASE-12751-v12.patch,
> HBASE-12751-v13.patch, HBASE-12751-v14.patch, HBASE-12751-v15.patch,
> HBASE-12751-v16.patch, HBASE-12751-v17.patch, HBASE-12751-v2.patch,
> HBASE-12751-v3.patch, HBASE-12751-v4.patch, HBASE-12751-v5.patch,
> HBASE-12751-v6.patch, HBASE-12751-v7.patch, HBASE-12751-v8.patch,
> HBASE-12751-v9.patch, HBASE-12751.patch
>
>
> Right now every write operation grabs a row lock. This is to prevent values
> from changing during a read modify write operation (increment or check and
> put). However it limits parallelism in several different scenarios.
> If there are several puts to the same row but different columns or stores
> then this is very limiting.
> If there are puts to the same column then mvcc number should ensure a
> consistent ordering. So locking is not needed.
> However locking for check and put or increment is still needed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
