hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Clint Morgan <clint.mor...@troove.net>
Subject Re: Questions on the transactional package
Date Thu, 09 Jul 2009 00:15:01 GMT
Those commitPending transactions have not been committed when the
transaction starts, but may be committed when the transaction is ready to
commit. Thus we will need to verify that we don't conflict with them (if
they commit first). Otherwise we could have read one of their rows before
they get committed and then violate transaciton atomicity.

At commit time we figure out the rest of the transacitons that we need to
check against by looking though all transactions that have committed since
the current transaciton began. We use the sequence number to calculate this.
The commitPending ones are added explicity because they have a sequence
number before our startSeqNum...

You are right about threading/iteration issue. The current code iterates
over a copy of commitPendingTransactions to fix that potential CME. But
thinking on it there is still a race condition here, so a lock would be
needed. I'll look into it before 0.20...

-clint

On Wed, Jul 8, 2009 at 4:29 PM, Ski Gh3 <skigh3@gmail.com> wrote:

> Hi,
>
> I was browsing the transactional package to understand how it works, and
> got
> a little confused and wonder if someone can help me out:
>
> In the TransactionalRegion class, why is the commitPendingTransactions set
> added to the current transaction in beginTransaction method?
> shouldn't it be in the RequestCommit method?
>
> plus, shouldn't this code be protected using synchronized, even though
> commitPendingTransactions is a synchronized set, since this is a iteration?
>
> the code is as follows:
>
> // Order is important here
>    for (TransactionState commitPending : commitPendingTransactions) {
>      state.addTransactionToCheck(commitPending);
> }
>
> Thanks!
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message