[
https://issues.apache.org/jira/browse/HBASE-12751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14641799#comment-14641799
]
stack commented on HBASE-12751:
-------------------------------
Should we read at with the same mvcc in these two locations below (could edit
we write the WAL disagree with the file sequenceid we write out)?
{code}
97 RegionEventDescriptor regionEventDesc =
ProtobufUtil.toRegionEventDescriptor(
98 - RegionEventDescriptor.EventType.REGION_CLOSE, getRegionInfo(),
getSequenceId().get(),
99 + RegionEventDescriptor.EventType.REGION_CLOSE, getRegionInfo(),
mvcc.memstoreRead.get(),
100 getRegionServerServices().getServerName(), storeFiles);
101 - WALUtil.writeRegionEventMarker(wal, getTableDesc(), getRegionInfo(),
regionEventDesc,
102 - getSequenceId());
103 + WALUtil.writeRegionEventMarker(wal, getTableDesc(), getRegionInfo(),
regionEventDesc);
104 •
105 // Store SeqId in HDFS when a region closes
106 // checking region folder exists is due to many tests which delete
the table folder while a
107 // table is still online
108 if (this.fs.getFileSystem().exists(this.fs.getRegionDir())) {
109 WALSplitter.writeRegionSequenceIdFile(this.fs.getFileSystem(),
this.fs.getRegionDir(),
110 - getSequenceId().get(), 0);
111 + mvcc.memstoreReadPoint(), 0);
{code}
... and later on so log matches the condition check.
bq. That allows a creating the sequence id/mvcc number for real.
So mvcc has its own running sequenceid-like thing now and it runs independent
of sequenceid. Previous we were just using WAL sequenceid everywhere (though we
had that +1B hackery going on). It took some work to get us down to one
sequence only. The patch adds back another. If just fixing the ordering problem
(ordering in memstore vs WAL), could we just add to MemStore in the WAL
appender/ringbuffer consuming thread? Would that be too slow? You'd have to
rollback still if failure but less moving parts?
bq. mvcc.completeMemstoreInsert(mvcc.beginMemstoreInsert());
The above seems odd. Make a method on mvcc to do the above? Could return the
current read point (going by what is needed later in the patch)
And the mvcc initialize semantic has changed? It used to be
advanceMemstoreReadPointIfNeeded but now we override initialize and call it
often. It is a bit hard to follow what initialize does now given it is called
frequently.
Why does WALKey take an mvcc? And then, how comes you can get mvcc from WALKey?
I'd think WALKey would be made once on construction.... and would not be
concerned with stuff like mvccs and writeEntries. Or if it was, that it'd be
internal to WALKey implementation (You'd not be able to get mvcc from WALKey).
WALKey has an mvcc but then you can call setWriteEntry? Would be cool if WALKey
knew nought of mvccs.
In the below:
{code}
115 we = mvcc.beginMemstoreInsert();
116 regionSequenceId = we.getWriteNumber();
{code}
... is this the region sequenceid? Or is it the mvcc number?
> 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)
