It depends on how you about the rpc request. For hbase, there will be no
write conflict, but a write operation can only be finished iff all the
write operations with a lower mvcc number have been finished. So if you
just stop a write operation without recovering the mvcc(I do not know how
to recover but I think you need to something...) then the writes will be
stuck.

And one more thing, for read operation you may interrupt it at any time,
but for write operation, I do not think you can re-execute it with a new
mvcc number if the WAL entry has already been flushed out. That means, the
re-execution process will be different if you about the write operation at
different stages.

Thanks.

2017-04-10 6:47 GMT+08:00 杨苏立 Yang Su Li <[email protected]>:

> We are trying to implement speculative rpc handling for our workloads. So
> we want allow RPC Handler to stop executing an RPC call, put it back to the
> queue, and later re-execute it.
>
> If at time t1, we execute and RPC call half way, aborts, and put the call
> back to the queue.
> Then at time t2 another RPC handler picks the call and re-execute it.
> I understand that we might get a different mvcc number and different
> results at t2 compared to we execute it at t1.
> My question is that: would this situation any different compared to the
> situation where the call was never executed at t1, and is executed at t2
> for the first time.
>
>
> My guess is that since at t1 we may already gotten an mvcc number, so it
> might potentially cause some write conflicts and certain write operations
> to retry. But correctness wise, is there any difference?
>
> Thanks a lot!
>
> Suli
>
>
> On Sun, Apr 9, 2017 at 5:14 PM, Jerry He <[email protected]> wrote:
>
> > I don't know what your intention and your context are.
> >
> > You may get a different mvcc number and get different results next time
> > around if there are concurrent writes.
> >
> > Thanks,
> >
> > Jerry
> >
> > On Sun, Apr 9, 2017 at 12:48 PM 杨苏立 Yang Su Li <[email protected]>
> wrote:
> >
> > > Hi,
> > >
> > > I am wondering, for read requests like Get/MultiGet/Scan, is the RPC
> > > handling idempotent in HBase?
> > >
> > > More specifically, if in the middle of RPC handling we stop the
> handling
> > > threads, puts the RPC call back to the queue, and later another RPC
> > Handler
> > > picks up this call and starts all over again, will the result be the
> same
> > > as if this call is being handled for the first time now? Or are their
> any
> > > unexpected side effects?
> > >
> > > Thanks!
> > >
> > > Suli
> > >
> > > --
> > > Suli Yang
> > >
> > > Department of Physics
> > > University of Wisconsin Madison
> > >
> > > 4257 Chamberlin Hall
> > > Madison WI 53703
> > >
> >
>
>
>
> --
> Suli Yang
>
> Department of Physics
> University of Wisconsin Madison
>
> 4257 Chamberlin Hall
> Madison WI 53703
>

Reply via email to