Another way would be to make your PK a clustering key with Id as PK and time as clustering with type TimeUUID. Then you’ll always insert records, never update, for each “transaction” you’ll keep a row in the partition. Then when you’ll read all the rows for that partition by Id, you’ll process all of them to know the real status. For example, if final status must be “completed” and you have:
Id, TimeUUI, status
1, t0, added
1, t1, added
1, t2, completed
1, t3, added
When reading back you’ll just discard the last row.
If you’re only concerned about “insert or update” case but the data is actually the same you can always insert. If you insert on an existing record it will just overwrite it, if you update without an existing record it will insert data. In Cassandra there is not much difference between insert and update operations.
From: Rajesh Kishore [mailto:rajesh10sinha@xxxxxxxxx]
I think LWT feature is introduced for your kind of usecases only - you don't want other requests to be updating the same data at the same time using Paxos algo(2 Phase commit).
So, IMO your usecase makes perfect sense to use LWT to avoid concurrent updates.
If your issue is not the concurrent update one then IMHO you may want to split this in two steps:
- get the transcation_type with quorum factor (or higher consistency level)
- And conditionally update the row with with quorum factor (or higher consistency level)
But remember, this wont be atomic in nature and wont solve the concurrent update issue if you have.
On Wed, Jun 20, 2018 at 2:59 AM, manuj singh <s.manuj545@xxxxxxxxx> wrote: