Mailing-List: contact user-help@accumulo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@accumulo.apache.org
Received-SPF: pass (athena.apache.org: domain of eric.newton@gmail.com
 designates 209.85.223.169 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <8981F843EE8088488986AB76F63A790313E02090@endeavour.eoir.com>
References: <8981F843EE8088488986AB76F63A790313E02090@endeavour.eoir.com>
Date: Tue, 16 Oct 2012 18:19:12 -0400
Message-ID: 
 <CADxc9Bk2LC_uX0c3SiDcygGF-mr1O_uxt3swYFsyCp+2iQRxTw@mail.gmail.com>
Subject: Re: Concurrent updates
From: Eric Newton <eric.newton@gmail.com>
To: user@accumulo.apache.org
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Accumulo does not have locks, nor does it have transactions.  It does
support atomic, isolated updates within a row.

Accumulo also supports a very specific kind of update which is very
helpful in the case of sums and aggregates.

For example, if I wanted to provide a "count" I can insert:

row X, column A, value 1:  (X, A, 1)

to indicate some event occurred.  Eventually, in the database, there
will be lots of these values at a row/column:

(X, A, 1)
(X, A, 1)
(X, A, 1)

You can insert code to reduce these values when you scan, kind of like
a Combiner in a map/reduce job.  This code will emit:

(X, A, 3)

The same code can also be incorporated into the compaction scheme, so
eventually, the database will actually store:

(X, A, 3)

This mechanism can be used to "sum" more complex information.  The
point is that you can take advantage of the log-structured merge tree
to defer the computation to some point in the future when you have a
very high degree of isolation.  Yet you can still perform the
computation as-needed right after you add insert information.

Of course, it does not provide a substitute for locks or transactions
and may not cover your use case.  But it covers a surprising number of
them.

-Eric

On Tue, Oct 16, 2012 at 4:51 PM, Sami Omer <somer@eoir.com> wrote:
> Hello everyone,
>
>
>
> I=92m using Accumulo 1.3.6 as the backend for a project that I=92ve been =
working
> on, I=92m relatively new to it.
>
>
>
> I have written a client that appends some of the data stored in my Accumu=
lo
> backend. Now, if I have multiple clients running and  they perform the
> read/update operation simultaneously I might run into concurrency problem=
s.
> So, I was wondering what could be done to prevent such race conditions. D=
oes
> Accumulo have an equivalent to RDBMS=92s transactions? Or is there a way =
to
> lock rows that are currently being processed for read/update? Do you have
> any other ways to solve the issue of concurrent updates?
>
>
>
> Your help is greatly appreciated.
>
>
>
> Sami