I've solved this for other systems, and it might work here.
Add a Guid as a field to the record.
When you update the document, check to make sure the Guid hasn't changed since
you read it. If the Guid is the same, go ahead and save the document along
with a new Guid.
This keeps you from lockin
I think the anti-pattern is more about the read/write trying to be atomic.
You might want to logically lock your record unless you are pretty sure you
have figured out how to keep users from overwriting each others edits is all.
tc
From: Robert Wille [mailto:rwi...@fold3.com]
Sent: Friday, Janu
, locking won't fix the problem. He's getting the problem on a single
thread.
I'm pretty sure that if updates can occur within the same millisecond (or more,
if there is clock skew), there is literally nothing you can do to make this
pattern work.
Robert
From: Todd Carrico m
That, or roll your own locking. Means multiple updates, but it works reliably.
tc
From: Robert Wille [mailto:rwi...@fold3.com]
Sent: Friday, January 10, 2014 4:25 PM
To: user@cassandra.apache.org
Subject: Re: Read/Write consistency issue
Cassandra is a last-write wins kind of a deal. The last w
Are there published best practices for managing Schema with CQL 3.0?
Say for bootstrapping the schema for a new feature?
Do folks query the system.schema_keyspaces on startup and create the necessary
schema if it doesn't exist?
Or do you have one-off scripts that create schema?
Is there a more
