On duplicate key update

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

Re: On duplicate key update

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

Re: java.io.IOException: Added a key not lexically larger than previous

Looks like problem begun with 4.14.2 Maybe somehow https://issues.apache.org/jira/browse/PHOENIX-5266 can re-apply mutations to main table with bugs? > On 20 Jun 2019, at 04:16, Alexander Batyrshin <0x62...@gmail.com> wrote: > > Hello, > Are

Blog post on load balancing Phoenix Query Server with sticky sessions

Hello, We have published a blog post on how we have achieved load balancing for Apache Phoenix Query Server with sticky sessions. https://medium.com/helpshift-engineering/smart-sticky-sessions-using-haproxy-for-apache-phoenix-911bdca7e2c