Re: On duplicate key update

2019-08-27 Thread 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

Re: On duplicate key update

2019-08-27 Thread 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

Re: On duplicate key update

2019-08-26 Thread Josh Elser
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