Thanks a lot for clarifying !
That was very helpful.
Regards,
Mridul
Clint Morgan wrote:
Sorry I have been so slow in understanding. I now see what you mean. I was
trying to explain how I thought it *should* work, rather than what it
actually does now.
That method of aborting on an exception
Sorry I have been so slow in understanding. I now see what you mean. I was
trying to explain how I thought it *should* work, rather than what it
actually does now.
That method of aborting on an exception in the 2nd phase is incorrect for
the reason you mention: For a 3 region transaction, we could
Clint Morgan wrote:
After the 2PC process has determined that a commit should happen there is no
roll-back. The commit must be processed.
From org.apache.hadoop.hbase.client.transactional.TransactionManager
doCommit() which is the 2nd phase of 2-phase commit, on throwing
Exception results in
After the 2PC process has determined that a commit should happen there is no
roll-back. The commit must be processed.
So in your example, a commit has been approved, and one the of the regions
is told to go ahead and commit. The region triggers the index Put, but then
fails on his Puts (like out o
Clint Morgan wrote:
The client drives the 2PC process, so after it has established that a trx
may be committed (by asking each region), it tells each region to commit.
Only then does it actually start to write to the base/indexed tables. So we
don't really have a problem with "overlapping rollbac
The client drives the 2PC process, so after it has established that a trx
may be committed (by asking each region), it tells each region to commit.
Only then does it actually start to write to the base/indexed tables. So we
don't really have a problem with "overlapping rollbacks", because a rollbac
urtell
To: hbase-user@hadoop.apache.org
Sent: Mon, 4 January, 2010 6:43:15 AM
Subject: Re: Secondary indexes and transactions
> > Yes. But IIUC, the client is running a transaction that spans the update to
> > the two tables. It'll take care of the undo should say the update to the
&
> > Yes. But IIUC, the client is running a transaction that spans the update to
> > the two tables. It'll take care of the undo should say the update to the
> > transacation table fails.
> >
> Isn't the update to the secondary index implicitly done ? As in, does
> the client 'see' this update ?
stack wrote:
On Sun, Jan 3, 2010 at 10:46 AM, Mridul Muralidharan
wrote:
I was wondering about the atomicity guarantees when using secondary
indexes from within a transaction.
You are talking about indexed hbase from transactional hbase contrib?
Yes, exactly.
From what I could gathe
On Sun, Jan 3, 2010 at 10:46 AM, Mridul Muralidharan
wrote:
>
> I was wondering about the atomicity guarantees when using secondary
> indexes from within a transaction.
>
>
You are talking about indexed hbase from transactional hbase contrib?
> From what I could gather, updates to the index tab
Hi,
I was wondering about the atomicity guarantees when using secondary
indexes from within a transaction.
From what I could gather, updates to the index table goes through its
own (set of) rpc before the underlying transactional table is updated -
and these update happens outside of the
11 matches
Mail list logo
