hbase-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Clint Morgan" <cm-pub...@troove.net>
Subject Re: Loosened transaction isolation level
Date Mon, 27 Oct 2008 16:55:10 GMT
Yeah, the scanner's are definitely overly conservative. I needed this
because for example I am scanning a key range to guarantee that the update
I'm processing has a unique column value. The current implementation could
be improved to look more carefully if the scan really did pass any rows
which were in the write sets of other transactions (EG. Keep the start and
end points of the scanner)

But it would also make sense to allow less restrictive transaction models,
and an enum passed to beginTransaction makes sense. Please open a JIRA. (And
maybe post a patch...)


On Sun, Oct 26, 2008 at 10:33 PM, Jaeyun Noh <metalain@gmail.com> wrote:

> Hi all, I have a question on transaction model implemented in HBase
> (TransactionalRegion, which extends HRegion).
> During the commit phase, HBase transaction checks conflicts between
> read and write according to the timestamp-based CC.
> In that code, I found that update transactions with any scan operation
> seems to be rolled back by other update transactions. It will
> seriously reduce success ratio of transaction commits when a scan
> interleaves updates. Phantom reads can be prevented by key range
> locking in theory, but this is impractical. So I understand that a
> conservative model is used. Just locking a whole table.
> In our case, we don't want a serious transaction isolation level. We
> may don't need to prevent phantom read and even a non-repeatable read.
> We just need a read-commit isolation level, preventing a dirty read.
> In this case, I wonder that this conflict check model is really needed
> in our use case.
> So what about supporting more loosen transaction model in addition? We
> can live with ReadCommitted isolation level. Maybe we can set an enum,
> which indicates an isolation level, in the beginTransaction() method.
> FYI, Following code is the conflict check method in TransactionState
> used in TransactionalRegion class.
>  private boolean hasConflict(final TransactionState checkAgainst) {
>    if (checkAgainst.getStatus().equals(TransactionState.Status.ABORTED)) {
>      return false; // Cannot conflict with aborted transactions
>    }
>    for (BatchUpdate otherUpdate : checkAgainst.getWriteSet()) {
>      if (this.hasScan) {
>        LOG.info("Transaction" + this.toString()
>            + " has a scan read. Meanwile a write occured. "
>            + "Conservitivly reporting conflict");
>        return true;
>      }
>      if (this.getReadSet().contains(otherUpdate.getRow())) {
>        LOG.trace("Transaction " + this.toString() + " conflicts with "
>            + checkAgainst.toString());
>        return true;
>      }
>    }
>    return false;
>  }
> Regards,
> Jaeyun Noh.

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