Regarding Client Side Recovery

[brohitr...@gmail.com]

In ReTSO paper, no where they have specified about Client Side Recovery. Is Client Side Recovery provided by OMID?

Since Client Side Recovery is also as crucial as TSO Recovery

[Daniel Gómez Ferro]

Hi,

Omid handles client side recovery. There are two cases:

- Client failure: nothing to recover from, uncommitted transactions will be aborted and aborted transactions will be cleaned up eventually.

- TSO failure: in this case we abort all running transactions, so we handle it as well. There is a small corner case, where a transaction could have been committed just before the TSO failed. Currently the client won't know that the transaction actually succeeded, but this should be easy to fix.

I hope this clears up your concerns, if you have more doubts please ask!

Cheers,

Daniel

On Wed, May 8, 2013 at 7:53 PM, <brohitr...@gmail.com> wrote:

In ReTSO paper, no where they have specified about Client Side Recovery. Is Client Side Recovery provided by OMID?

Since Client Side Recovery is also as crucial as TSO Recovery

--
You received this message because you are subscribed to the Google Groups "Omid" group.
To unsubscribe from this group and stop receiving emails from it, send an email to omid-project...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[brohitr...@gmail.com]

Thanx for the reply.

For every PUT through OMID there are essentially Two PUTS

1) Temporary PUT with Start Time Stamp

2) Updating Temporary PUT with Commit Time Stamp

If crash happens after Temporary PUT, will OMID clean up that values through Book Keeper

If crash happens after Final PUT (still some more operations are left over), will OMID clean up that values

[Daniel Gómez Ferro]

Omid design is quite different from the original ReTSO design, it is covered here: http://www.sigops.org/sosp/sosp11/posters/summaries/sosp11-final12.pdf

In Omid there is only one write to HBase per PUT operation, we don't update the commit timestamp later on. the Status Oracle maintains a mapping from StartTimestamp to CommitTimestamp, which is replicated to the clients. This mapping allows clients to know the commit timestamp of any written value. 

Cheers,

Daniel

[brohitr...@gmail.com]

Suppose i had 3 PUT's as part of my transaction.

At the time of COMMIT no conflict has been detected.

First PUT has been performed, before the second PUT the client machine has crashed. We need to UNDO the first PUT right?  

Regards

Rohit

[Matthieu Morel]

On Thursday, May 9, 2013 11:45:29 AM UTC+2, brohitr...@gmail.com wrote:

Suppose i had 3 PUT's as part of my transaction.

At the time of COMMIT no conflict has been detected.

First PUT has been performed, before the second PUT the client machine has crashed. We need to UNDO the first PUT right?  

Note that in Omid data can be written in hbase even though it is not yet committed.

In my understanding, here is what happens in your scenario:

1/ client initiates a transaction, by asking the transaction oracle, which returns a start timestamp t1

2/ clients performs 3 put operations. They are written in hbase with timestamp t1.

3/ client initiates commit: asks the transaction oracle. If no conflict is detected, the transaction oracle validates the commit and keeps a commit timestamp t2, which is also returned to the user.

There is nothing to undo: the data is already in hbase, with timestamp t1, and the oracle is the authority that decides whether the transaction is committed or not. Either all written data for t1 is committed, or nothing is committed for t1.

 

Transactions initiated after t2 will see the data written in t1 if commit was succesful, otherwise they won't "see" that data.

Hope this helps,

Matthieu

[Youngjoon Kim]

Hi, 

Daniel, I have a question about client failure.

You said that "aborted transactions will be cleaned up eventually",

What does "clean up" mean? Does it mean that hbase cells written by an aborted transaction will be deleted eventually?

Thanks,

Youngjoon

2013년 5월 9일 목요일 오후 5시 28분 16초 UTC+9, Daniel Gómez Ferro 님의 말:

[brohitr...@gmail.com]

Thanx for the reply,

Suppose Before the third step(Initiating Commit), if the client crashes..how the Inconsistent Data in HBase will be removed

Regards

Rohit

[Matthieu Morel]

On Friday, May 10, 2013 5:24:19 AM UTC+2, brohitr...@gmail.com wrote:

Thanx for the reply,

Suppose Before the third step(Initiating Commit), if the client crashes..how the Inconsistent Data in HBase will be removed

There is a cleanup routine that runs upon compactions. See the com.yahoo.omid.regionserver.Compacter class.


Matthieu