On duplicate key update

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

On duplicate key update

Jon Strayer

How does atomic update work with multiple clients?  Assuming that there is no matching record to begin with the access won’t be locked.  It seems like two threads could write conflicting data since they both see no existing record (NER).  Is that correct? Or is there something that will serialize the writes so that only one of them sees the NER state?

Reply | Threaded
Open this post in threaded view
|

Re: On duplicate key update

Josh Elser-2
Out of the box, Phoenix will provide the same semantics that HBase does
for concurrent updates to a (data) table.

https://hbase.apache.org/acid-semantics.html

If you're also asking about how index tables remain in sync, the answer
is a bit more complicated (and has changed in recent versions).

On 8/26/19 2:51 PM, Jon Strayer wrote:
> How does atomic update work with multiple clients?  Assuming that there
> is no matching record to begin with the access won’t be locked.  It
> seems like two threads could write conflicting data since they both see
> no existing record (NER).  Is that correct? Or is there something that
> will serialize the writes so that only one of them sees the NER state?
>
Reply | Threaded
Open this post in threaded view
|

Re: On duplicate key update

Jon Strayer
Just to make sure I understand, anytime an atomic upsert is executed Phoenix translates that into a checkAndPut.  Is that correct?

From the Atomic Upsert documentation:
"On the server-side, when the commit is processed, the row being updated will be locked while the current column values are read and the ON DUPLICATE KEY clause is executed."

What I'm not clear on is when the lock happens.  Does it happen every time a upsert with an "on duplicate key" clause is executed or only after the duplicate key is detected?

Also, if there are two threads attempting to write to the same non-existing row, is there a race condition where neither thread executes it "on duplicate key" clause?

On 8/26/19, 7:28 PM, "Josh Elser" <[hidden email]> wrote:

    Out of the box, Phoenix will provide the same semantics that HBase does
    for concurrent updates to a (data) table.
   
    https://urldefense.com/v3/__https://hbase.apache.org/acid-semantics.html__;!YggOdHcy3_sa5w!7XIAKeE5bdWVHeRnJhaMbEwH9vjnhUzpxgoFvOlQBqYoCWp72RMXHdT636yxH4bg3to$ 
   
    If you're also asking about how index tables remain in sync, the answer
    is a bit more complicated (and has changed in recent versions).
   
    On 8/26/19 2:51 PM, Jon Strayer wrote:
    > How does atomic update work with multiple clients?  Assuming that there
    > is no matching record to begin with the access won’t be locked.  It
    > seems like two threads could write conflicting data since they both see
    > no existing record (NER).  Is that correct? Or is there something that
    > will serialize the writes so that only one of them sees the NER state?
    >
   

Reply | Threaded
Open this post in threaded view
|

Re: On duplicate key update

James Taylor
The lock will happen every time an "on duplicate key" clause is executed. Conceptually it's like a checkAndPut, but it's batched. If two threads attempt to write the same non-existent row, one of them will get there first and get the lock, while the other would wait behind it (and subsequently trigger the "on duplicate key" logic).

On Tue, Aug 27, 2019 at 9:05 AM Jon Strayer <[hidden email]> wrote:
Just to make sure I understand, anytime an atomic upsert is executed Phoenix translates that into a checkAndPut.  Is that correct?

From the Atomic Upsert documentation:
"On the server-side, when the commit is processed, the row being updated will be locked while the current column values are read and the ON DUPLICATE KEY clause is executed."

What I'm not clear on is when the lock happens.  Does it happen every time a upsert with an "on duplicate key" clause is executed or only after the duplicate key is detected?

Also, if there are two threads attempting to write to the same non-existing row, is there a race condition where neither thread executes it "on duplicate key" clause?

On 8/26/19, 7:28 PM, "Josh Elser" <[hidden email]> wrote:

    Out of the box, Phoenix will provide the same semantics that HBase does
    for concurrent updates to a (data) table.

    https://urldefense.com/v3/__https://hbase.apache.org/acid-semantics.html__;!YggOdHcy3_sa5w!7XIAKeE5bdWVHeRnJhaMbEwH9vjnhUzpxgoFvOlQBqYoCWp72RMXHdT636yxH4bg3to$

    If you're also asking about how index tables remain in sync, the answer
    is a bit more complicated (and has changed in recent versions).

    On 8/26/19 2:51 PM, Jon Strayer wrote:
    > How does atomic update work with multiple clients?  Assuming that there
    > is no matching record to begin with the access won’t be locked.  It
    > seems like two threads could write conflicting data since they both see
    > no existing record (NER).  Is that correct? Or is there something that
    > will serialize the writes so that only one of them sees the NER state?
    >