I put more comments on this:
HBASE-3021
Basically we needed to avoid duplicate timestamp KVs in memstore &
hfile, elsewise we might end up 'getting' the wrong value and thus
messing up the count.
With work on ACID by stack we can avoid using that.
-ryan
On Mon, Jan 10, 2011 at 11:23 AM, Stack <st...@duboce.net> wrote:
> Yeah, thats going away unless Ryan comes up w/ a reason for why we
> should keep it.
> St.Ack
>
> On Mon, Jan 10, 2011 at 12:29 AM, Ryan Rawson <ryano...@gmail.com> wrote:
>> There was a good, but complex reason. Its going away with stacks time stamp
>> patch. I'll see if I can do a better email tomorrow.
>> On Jan 9, 2011 11:42 PM, "Dhruba Borthakur" <dhr...@gmail.com> wrote:
>>> I am looking at Hregion.incrementColumnValue(). It has the following piece
>>> of code
>>>
>>> // build the KeyValue now:
>>> 3266 KeyValue newKv = new KeyValue(row, family,
>>> 3267 qualifier, EnvironmentEdgeManager.currentTimeMillis(),
>>> 3268 Bytes.toBytes(result));
>>> 3269
>>> 3270 // now log it:
>>> 3271 if (writeToWAL) {
>>> 3272 long now = EnvironmentEdgeManager.currentTimeMillis();
>>> 3273 WALEdit walEdit = new WALEdit();
>>> 3274 walEdit.add(newKv);
>>> 3275 this.log.append(regionInfo,
>>> regionInfo.getTableDesc().getName(),
>>> 3276 walEdit, now);
>>> 3277 }
>>>
>>> It invokes EnvironmentEdgeManager.currentTimeMillis() twice, once for
>>> creating the new KV and then another time to add it to the WAL. Is this
>>> significant or just an oversight? Can we instead invoke it once before we
>>> create the new key-value and then use it for both code paths?
>>>
>>> Thanks,
>>> dhruba
>>>
>>> --
>>> Connect to me at http://www.facebook.com/dhruba
>>
>
